Сессии в REST сервисах

Question

Я занимаюсь разработкой небольшого сервиса REST, который должен поддерживать постоянство клиентских сессий.Как вы знаете, из-за REST мы не можем хранить какие-либо данные клиента на сервере, данные должны храниться на стороне клиента, а запрос клиента должен быть самодостаточным.Итак ... как мы можем хранить клиентские сессии?Ища в интернете, я нашел несколько способов, как это реализовать.Например: мы отправляем клиенту зашифрованный токен, который содержит идентификатор клиента (ник ... и т. Д.), Например token = AES (id, secretKey);и затем мы авторизуем пользователя для каждого запроса на расшифровку токена на сервере с секретным ключом.Кто-нибудь может что-нибудь посоветовать?Может быть, есть еще один хороший способ сделать ту же функциональность.Какой алгоритм шифрования будет предпочтительным для этого?Благодарю.

Answer 1

Вы упомянули:

Как вы знаете, из-за REST мы не можем хранить данные клиента на сервер, данные должны храниться на стороне клиента и запрос клиента должен быть самодостаточным.

REST не говорит, что вы не можете хранить данные клиента на сервере; он просто говорит, что вы не должны хранить состояние приложения , что вы можете считать «тем, что пытается сделать этот клиент».

Если вы в первую очередь пытаетесь использовать концепцию аутентифицированных пользователей, тогда стандартный файл cookie для входа в систему будет работать нормально и не будет "unRESTful".

Answer 2

Все сводится к вашему ответу на этот вопрос: зачем вам вообще нужна концепция «сессии»?

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

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

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