REST и HttpSession объект

Question

Я знаю, что REST не должен использовать HttpSession.С другой стороны, служба REST работает в контейнере сервлета.Из того, что я увидел, объект HttpSession будет создан только тогда, когда:

HttpSession session = request.getSession(); 

выполняется код.Это всегда так?Помимо использования JSP?

Мой вопрос: будут ли HttpSession объекты создаваться при выполнении метода REST или нет?

Допустим, я использую инфраструктуру JAX-RS,если это может иметь какое-либо значение.
Если такие объекты не создаются, это фактически может означать, что размер памяти сервера может не увеличиваться независимо от того, сколько клиентов использует его на сервере.

Answer 1

HTTP-сессии на самом деле довольно часто используются с интерфейсами REST, но никогда не должны содержать ничего действительно критического. Таким образом, они могут использоваться, чтобы содержать факт, что вы аутентифицировались или каков ваш предпочтительный порядок по умолчанию для некоторого списка; в первом случае вы также можете одновременно поддерживать другие механизмы аутентификации, позволяющие работать без сохранения состояния, а во втором вы также можете легко поддерживать явные переопределения. Пока вы не требуете сеанса - хорошо, при условии, что ваш сайт использовал HTTP BASIC auth для аргумента; если вы используете OAuth, то вам нужно, чтобы сеансы были включены, чтобы остановить снижение производительности - тогда вы все еще потенциально достаточно близки к RESTful (в этой области наверняка; REST в конце концов не означает «не использовать сеансы»).

Есть ли опасения по поводу того, как долго длится сеанс до истечения времени ожидания? Ну, может быть, но не совсем. Сеанс - это действительно объект, который вы сопоставили с некоторой таблицей базы данных, и вы можете настроить политику истечения срока действия для них так, чтобы они сохранялись достаточно долго, чтобы поддерживать эффективное использование, не будучи чрезмерно обременительным. Это зависит от того, сколько клиентов используют сайт одновременно, каковы их модели использования и какие у вас есть ресурсы (конечно).

Answer 2

Я думаю, что это ограничение среды Java EE, в то время как я еще не видел, чтобы это делалось иначе, чем на любом другом сервере.Если вам нужен управляемый контейнер security-constraint, будет создан сеанс.

При этом вам не нужно реализовывать свой код для использования аутентификации, управляемой контейнером.Люди сами реализуют аутентификацию / механизмы входа в систему, такие как Shiro, а что нет.

Если вас беспокоит масштабируемость, вам, возможно, придется самостоятельно выполнять аутентификацию.Однако, прежде чем продолжить этот путь, подумайте о следующем ... сколько людей вы ожидаете использовать ваше приложение?Если вы не являетесь какой-то действительно крупной и популярной службой, такой как Facebook, Google и т. Д., Существующие аппаратные / облачные предложения должны быть в состоянии справиться с вашей нагрузкой с помощью HTTP-сессий с большим количеством свободного места.

Однако, если вы хотитечтобы сделать это самостоятельно, я предлагаю следующее:

1. клиент, не прошедший проверку подлинности, передает учетные данные (с помощью WWW-Authorization проще всего тестировать)
2. учетные данныепроверены и токен возвращается.Токен представляет собой зашифрованную зашифрованную строку, содержащую идентификатор клиента, срок действия и токен повторной проверки.Этот токен передается обратно клиенту с помощью Set-Cookie
3. Клиент делает будущие запросы с Cookie, содержащим токен
4. Токен может использоваться до тех пор, покасрок его действия не истек, это будут просто криптографические вычисления на серверном узле, и, следовательно, при необходимости его можно масштабировать на несколько серверов. Нет единого хранилища данных для обработки.
5. Маркер reauth можно использовать для генерацииновый токен для клиента в случае его истечения (это полезно для пользовательских приложений, где взаимодействие может длиться минуты).

Вы можете добавить корпоративный кэш для хранения того, какие из них по-прежнему действительны, за счет:дополнительный бэкэнд-звонок.