Що означає Stateless в контексті REST?

Junior Level

Stateless (без збереження стану) означає, що сервер не зберігає інформацію про сесію клієнта між запитами. Кожен запит обробляється так, ніби він був першим.

Це означає, що серверу не потрібно пам’ятати, ким ви були 5 секунд тому. Кожен запит — як перший контакт з незнайомцем: клієнт повинен пред’явити всі необхідні дані (токен, параметри).

Основні принципи:

Кожен запит незалежний: Сервер не пам’ятає, що клієнт робив до цього
Клієнт зберігає стан: Вся інформація про сесію (токен, параметри) передається в кожному запиті
Сервер зберігає лише дані: Дані в БД (товари, користувачі) — це не стан сесії, це дозволено

Приклад:

// Кожен запит містить токен авторизації
// Токен передається щоразу, тому що сервер не пам'ятає вас між
// запитами — це і є Stateless.
GET /users/1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

GET /users/1/orders
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Переваги Stateless:

Оскільки серверу не потрібно зберігати сесію, будь-який запит може піти на будь-який сервер. Не потрібен sticky session, не потрібна синхронізація сесій між нодами.
Будь-який сервер може обробити будь-який запит
Простіше деплой і обслуговування

Middle Level

Де зберігається стан?

На сервері (Resource State): Дані в базі даних — це дозволено
На клієнті (Session State): Інформація про сесію (токен, фільтри) — це обов’язково для Stateless

TLS і Session Resumption

На рівні TCP/TLS стан існує:

TLS Session Tickets: Клієнт зберігає зашифрований тікет сесії
TLS Session ID: Дозволяє не робити повний Handshake при кожному запиті
REST залишається “Stateless” на рівні додатку, хоча інфраструктура може бути “Stateful”

Cookie передаються автоматично — зручно для браузерів
Authorization: Bearer більш гнучкі для мобільних додатків і допомагають уникнути CSRF атак

Token Bloat

Якщо зберігати в JWT занадто багато даних (ролі, права, ПІБ), розмір заголовка зросте:

Рішення: Зберігати в токені тільки sub (ID) і критичні scopes
Решту підтягувати з швидкого кешу за необхідності

Діагностика

Sticky Session Check: У Kubernetes/Nginx перевіряйте, чи не увімкнені sticky sessions
Distributed Tracing: Correlation ID (X-B3-TraceId) — єдиний спосіб пов’язати запити одного клієнта

Senior Level

Проблема JWT Revocation

JWT — Stateless-інструмент. Але якщо потрібно миттєво розлогінити користувача (при кражі токена), доведеться перевіряти “чорний список” токенів у Redis.

Парадокс: Щойно ви додаєте перевірку токена в БД/Redis при кожному запиті, ваш додаток фактично стає Stateful, оскільки залежить від спільного зовнішнього сховища станів сесій.

Вплив на Highload і Масштабування

Zero-Downtime Deployment

При Stateless-архітектурі можна вбити будь-який екземпляр сервера в будь-який момент. Клієнт просто переключиться на інший екземпляр.

Data Locality та Anycast IP

Stateless дозволяє використовувати Anycast IP. Запит з Токіо потрапить на сервер у Токіо, з Лондона — у Лондон. При наявності сесії довелося б синхронізувати її між континентами.

Прикордонні випадки

Race Conditions у сесії клієнта

Якщо клієнт надсилає два паралельні Stateless-запити, що оновлюють один ресурс:

Рішення: Optimistic Locking (If-Match + ETag)

Server-Side Rendering (SSR)

При SSR серверу часто потрібен стан для первинного відображення. Це створює гібридні моделі: перше завантаження Stateful, подальші API — Stateless.

Продуктивність

Race conditions вимагають Optimistic Locking через If-Match + ETag
При SSR часто виникають гібридні моделі (перше завантаження Stateful, API — Stateless)

🎯 Шпаргалка для співбесіди

Обов’язково знати:

Stateless означає, що сервер не зберігає стан сесії клієнта між запитами
Кожен запит має містити всю необхідну інформацію (токен, параметри)
Дані в БД (ресурси) — це не стан сесії, їх зберігання дозволено
Stateless дозволяє масштабувати сервер горизонтально без sticky sessions
JWT — Stateless-інструмент, але додавання перевірки в Redis робить систему Stateful
TLS Session Tickets існують на інфраструктурному рівні, але додаток залишається Stateless

Часті уточнюючі запитання:

В чому різниця між Session State і Resource State? — Session State (сесія клієнта) зберігається на клієнті, Resource State (дані в БД) — на сервері, це дозволено
Чому JWT revocation створює проблему? — Перевірка токена в БД/Redis при кожному запиті робить додаток Stateful
Як пов’язувати запити без сесії? — Через Correlation ID (X-B3-TraceId) для distributed tracing
Що таке Token Bloat? — Коли JWT містить занадто багато даних, збільшуючи розмір заголовка

Червоні прапорці (НЕ говорити):

«Stateless означає сервер взагалі нічого не зберігає» — сервер зберігає дані (БД), але не сесії
«Cookie і Bearer-токени — одне й те саме» — Cookie передаються автоматично, Bearer — вручну; Bearer захищає від CSRF
«Stateless неможливо масштабувати» — Stateless якраз спрощує горизонтальне масштабування

Пов’язані теми:

[[Що таке REST]]
[[Які HTTP методи ідемпотентні]]
[[В чому різниця між 401 та 403]]
[[Як організувати версіонування REST API]]