Относятся ли сессии к REST

Относятся ли сессии к REST?

Краткий ответ: Нет, сессии противоречат принципам REST. Давайте разберёмся, почему и как это работает в реальности.

REST-полнота и состояние

REST требует:

• Statelessness (отсутствие состояния на сервере)
• Каждый запрос содержит всю информацию для обработки
• Сервер не должен хранить информацию о клиенте между запросами

Сессии нарушают это потому что:

• Сервер хранит данные о пользователе (сессия)
• Клиент отправляет cookie с session id
• Сервер ищет сессию в памяти/Redis/DB

ПРОБЛЕМА: Сервер ДЕРЖИТ СОСТОЯНИЕ (session в памяти). ЭТО НЕ REST!

Как REST решает это: JWT Tokens

JWT подход (stateless):

• Сервер генерирует подписанный JWT
• Клиент отправляет Authorization: Bearer token
• Сервер проверяет подпись JWT (не ищет в памяти!)

ПЛЮСЫ:

• Сервер НЕ ХРАНИТ состояние (stateless)
• Токен содержит всю информацию (самоудостоверяющийся)
• Масштабируется на много серверов (no affinity needed)

Сессии в монолитных приложениях

Когда я использую сессии:

Express с сессией в Redis:

• Просто (встроено в Express)
• Безопасно (cookie httpOnly)
• Можно отозвать сессию сразу (logout)

Минусы:

• Статeful (сервер хранит состояние)
• Трудно масштабировать (нужна sticky session на load balancer)
• Сессия в памяти = потеряется при перезагрузке

JWT (RESTful подход)

Генерация токена:

• POST /login отправляет username/password
• Сервер возвращает подписанный JWT
• Клиент хранит в localStorage или sessionStorage

Использование токена:

• Клиент отправляет Authorization: Bearer token
• JwtAuthGuard проверяет подпись
• req.user содержит декодированный JWT

Плюсы:

• Stateless (REST-compliant)
• Масштабируется на много серверов (no state)
• Мобильный friendly (хранить в localStorage)
• Микросервисы (один token для всех сервисов)

Минусы:

• Сложнее (нужно управлять токенами)
• Нельзя отозвать сразу (действует до истечения)
• Токен может быть украден (если в localStorage)

Сессии плюс JWT (гибридный подход)

Лучшее из обоих миров:

1. POST /login возвращает accessToken (15m) и refreshToken (7d)
2. Клиент использует accessToken для запросов
3. Когда accessToken истекает, клиент отправляет refreshToken
4. Сервер проверяет refreshToken в Redis (можно отозвать!)
5. Сервер возвращает новый accessToken
6. POST /logout отзывает refreshToken в Redis

Плюсы:

• JWT для каждого запроса (stateless)
• Можно отозвать через refresh token (Redis)
• Access token короткий, не критично если украденный
• Масштабируется

Сессии в микросервисной архитектуре

Монолит плюс Сессии:

• Все API нужен доступ к Redis
• Тесно связанно, сложно масштабировать

Микросервисы плюс JWT:

• Auth Service выдаёт JWT Token
• Service A проверяет подпись JWT (не ищет в памяти)
• Service B проверяет подпись JWT (не ищет в памяти)
• Service C проверяет подпись JWT (не ищет в памяти)
• Результат: Полностью decoupled!

Сравнение

Мой выбор

• Монолит с одним фронтом: Сессии (просто)
• Микросервисы или API: JWT (масштабируемо)
• Критичны отзывы: JWT плюс Refresh tokens плюс Redis