Как понять, что "RESTful API является апатридом"?

Ответ 1

Быстрый ответ

В приложениях REST каждый запрос должен содержать всю информацию, необходимую для понимания сервером, а не зависящую от сервера, запоминающего предыдущие запросы.

Сохранение состояния сеанса на сервере нарушает ограничение без сохранения состояния архитектуры REST. Таким образом, состояние сеанса должно полностью обрабатываться клиентом.

Продолжайте читать для более подробной информации.

Состояние сеанса

Традиционные веб-приложения используют удаленные сеансы. При таком подходе состояние приложения полностью сохраняется на сервере. См. Следующую цитату от Роя Т. Филдинга dissertation:

3.4.6 Удаленная сессия (RS)

Стиль удаленной сессии - это вариант клиент-сервера, который пытается минимизировать сложность или максимизировать повторное использование компонентов клиента, а не серверного компонента. Каждый клиент инициирует сеанс на сервере, а затем вызывает серию сервисов на сервере и, наконец, выходит из сеанса. Состояние приложения полностью сохраняется на сервере. [...]

Хотя этот подход дает некоторые преимущества, он снижает масштабируемость сервера:

Преимущества стиля удаленного сеанса заключаются в том, что проще централизованно поддерживать интерфейс на сервере, уменьшая опасения относительно несоответствий в развертываемых клиентах при расширении функциональности и повышая эффективность, если взаимодействия используют расширенный контекст сеанса на сервер. Недостатком является то, что он снижает масштабируемость сервера из-за состояния сохраненного приложения и уменьшает видимость взаимодействий, поскольку монитор должен знать полное состояние сервера.

Ограничение без сохранения

Архитектурный стиль REST определяется в верхней части заданных ограничений, которые включают безгражданство сервера. Согласно Филдингу, ограничение без сохранения в REST определяется следующим образом:

5.1.3 Безгосударственный

[...] каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать любой сохраненный контекст на сервере. Таким образом, состояние сеанса полностью поддерживается клиентом. [...]

Это ограничение вызывает свойства видимости, надежности и масштабируемости:

Видимость улучшилась, потому что система мониторинга не должна смотреть за рамки единого запроса, чтобы определить полный характер запроса. Надежность улучшается, поскольку она облегчает задачу восстановления после частичных сбоев. Масштабируемость улучшается, поскольку отсутствие необходимости сохранять состояние между запросами позволяет серверному компоненту быстро освобождать ресурсы и дополнительно упрощает реализацию, поскольку серверу не нужно управлять использованием ресурсов по запросам.

Аутентификация и авторизация

Если клиент запрашивает защищенные ресурсы, требующие аутентификации, каждый запрос должен содержать все необходимые данные для надлежащей аутентификации/авторизации. См. Эту цитату из RFC 7235:

Предполагается, что HTTP-аутентификация является безстоящей: вся информация, необходимая для аутентификации запроса, ДОЛЖНА быть указана в запросе, а не зависит от сервера, который запоминает предыдущие запросы.

И данные аутентификации должны принадлежать стандартным HTTP Authorization. Из RFC 7235:

4.2. Авторизация

Поле заголовка Authorization позволяет агенту пользователя аутентифицироваться с сервером происхождения - обычно, но необязательно, после получения ответа 401 (неавторизованный). Его значение состоит из учетных данных, содержащих информацию аутентификации пользовательского агента для области запрашиваемого ресурса. [...]

^{Имя этого HTTP-заголовка является неудачным, поскольку оно содержит аутентификацию вместо данных авторизации.}

Для аутентификации вы можете использовать схему Basic HTTP Authentication, которая передает учетные данные как пары имени пользователя и пароля, закодированные с использованием Base64:

Authorization: Basic <credentials>

Если вы не хотите отправлять имя пользователя и пароль в каждом запросе, имя пользователя и пароль можно обменять на токен (например, JWT), который отправляется в каждом запросе. JWT может содержать имя пользователя, дату истечения срока действия и любые другие метаданные, которые могут иметь отношение к вашему приложению:

Authorization: Bearer <token>

Что может быть неправильно с вашим сервером

Как только у вас есть идентификатор сеанса, я думаю, что HTTP-сеанс создается где-то в вашем приложении. Это может быть в вашем собственном коде или в коде используемой структуры.

В приложениях Java вы должны убедиться, что следующие методы: not вызывается:

• HttpServletRequest#getSession()
• HttpServletRequest#getSession(boolean) с true