ведение сеанса в веб-сервисе REST

Question

У меня есть приложение COTS (приложение PLM), которое предоставило несколько API-интерфейсов SOAP для доступа.Поскольку этот SOAP API очень сложен, мы разрабатываем простой в использовании сервис-оболочку REST.Перед вызовом любого API в моем приложении COTS необходимо вызвать API аутентификации.В моей веб-службе оболочки REST у меня есть ресурс входа в систему, который вызывает API входа COTS SOAP.Чтобы не усложнять жизнь пользователям API, я сохраняю данные пользователя, вошедшего в систему, в сеансе пользователя.Во всех остальных ресурсах REST я извлекаю сеанс и проверяю, есть ли в сеансе сведения о пользователе.Если да, я продолжаю и вызываю SOAP API.если нет, я возвращаю правильный код статуса HTTP.Я использую Apache CXF для сервиса и клиента.Я предписываю своим пользователям API поддерживать сеанс в клиенте, например:

WebClient.getConfig (client) .getRequestContext (). Put (Message.MAINTAIN_SESSION, Boolean.TRUE);

В каждом руководстве по REST говорится, что REST не имеет состояния.Я сомневаюсь, что то, что я делаю, правильно, согласно стандартам REST.Пожалуйста, предложите.Спасибо

Answer 1

client.getRequestContext().put(Message.MAINTAIN_SESSION, Boolean.TRUE)

Этот код вызывает сохранение файлов cookie только для этого конкретного клиента. Если вы хотите, чтобы эти куки были доступны в другом клиенте, его необходимо запрограммировать. И если второй клиент получает дополнительные файлы cookie и вы хотите, чтобы эти файлы cookie были доступны и в первом клиенте, как это возможно?

Мне нужно что-то вроде корневого клиента, который поддерживает файлы cookie всех суб-клиентов. Все куки должны быть общими для всех клиентов. Как общий репозиторий cookie для всех клиентов. Кто-нибудь знает, как этого добиться?

Answer 2

По сути, идея REST - это интерфейс без состояния.Однако обычной практикой является использование какой-либо аутентификации для вызовов API, так как в большинстве случаев не все ресурсы должны быть общедоступными (например, временная шкала пользователя Twitter через API Twitter)

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