Java Interview Questions

Главная / Все ответы / REST HTTP

Вопрос 2 · Раздел 6

Что означает Stateless в контексте REST?

Это значит серверу не нужно помнить, кто вы были 5 секунд назад. Каждый запрос — как первый контакт с незнакомцем: клиент должен предъявить все необходимые данные (токен, параме...

Russian REST HTTP Исходный Markdown
Версии по языкам: English Russian Ukrainian

Junior Level

Stateless (без сохранения состояния) означает, что сервер не хранит информацию о сессии клиента между запросами. Каждый запрос обрабатывается как если бы он был первым.

Это значит серверу не нужно помнить, кто вы были 5 секунд назад. Каждый запрос — как первый контакт с незнакомцем: клиент должен предъявить все необходимые данные (токен, параметры).

Основные принципы:

  • Каждый запрос независим: Сервер не помнит, что клиент делал до этого
  • Клиент хранит состояние: Вся информация о сессии (токен, параметры) передаётся в каждом запросе
  • Сервер хранит только данные: Данные в БД (товары, пользователи) — это не состояние сессии, это разрешено

Пример:

// Каждый запрос содержит токен авторизации
// Токен передаётся каждый раз, потому что сервер не помнит вас между
// запросами — это и есть Stateless.
GET /users/1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

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

Преимущества Stateless:

  • Поскольку серверу не нужно хранить сессию, любой запрос может уйти на любой сервер. Не нужен sticky session, не нужна синхронизация сессий между нодами.
  • Любой сервер может обработать любой запрос
  • Проще деплой и обслуживание

Middle Level

Где хранится состояние?

  1. На сервере (Resource State): Данные в базе данных — это разрешено
  2. На клиенте (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]]