Хранится ли в стандарте REST состояние клиента

Хранение состояния клиента в REST

Принцип Statelessness

Нет, REST не хранит состояние клиента на сервере. Это одна из фундаментальных характеристик REST архитектуры, определённая Roy Fielding в его диссертации. Принцип называется Statelessness (отсутствие состояния).

Что это значит

Statelessness означает, что:

1. Сервер не помнит информацию о клиенте между запросами
2. Каждый запрос содержит всю необходимую информацию для его обработки
3. Сессии хранятся на клиенте, а не на сервере

Почему это важно

Масштабируемость:

# ❌ Stateful подход (плохо)
# Сервер 1 запомнил: user_id=123 logged_in=True
# Если запрос пойдёт на Сервер 2, он не знает о клиенте

# ✅ Stateless подход (хорошо)
# Клиент отправляет: Authorization: Bearer token_xyz
# Любой сервер может обработать запрос

При stateless можно использовать любой сервер из пула — не нужна привязка к одному серверу.

Надёжность:

# Если сервер упадёт, информация о клиентах потеряется
# Но в stateless архитектуре это не критично,
# потому что клиент отправит всё необходимое

Как на практике реализуется statelessness

1. Токены (самый частый способ)

from fastapi import FastAPI, Depends, HTTPException
from fastapi.security import HTTPBearer, HTTPAuthCredentials
import jwt

app = FastAPI()
security = HTTPBearer()

def verify_token(credentials: HTTPAuthCredentials = Depends(security)):
    try:
        payload = jwt.decode(credentials.credentials, "secret", algorithms=["HS256"])
        return payload["user_id"]
    except jwt.InvalidTokenError:
        raise HTTPException(status_code=401, detail="Invalid token")

@app.get("/profile")
async def get_profile(user_id: int = Depends(verify_token)):
    # Сервер не хранит info о юзере
    # Всё в токене на клиенте
    return {"user_id": user_id, "name": "John"}

Клиент передаёт токен в каждом запросе:

headers = {"Authorization": f"Bearer {access_token}"}
response = requests.get("https://api.example.com/profile", headers=headers)

2. Query параметры

@app.get("/orders")
async def get_orders(user_id: int, page: int = 1):
    # Клиент сам указывает user_id и пагинацию
    return {"orders": [], "page": page}

# Запрос: GET /orders?user_id=123&page=2

3. Body параметры

from pydantic import BaseModel

class SearchRequest(BaseModel):
    user_id: int
    query: str
    filters: dict

@app.post("/search")
async def search(req: SearchRequest):
    # Клиент передаёт всё в теле запроса
    results = db.search(req.query, filters=req.filters)
    return {"results": results, "total": len(results)}

Сравнение: Stateful vs Stateless

Stateful (старый веб)

# Session на сервере
sessions = {
    "abc123": {"user_id": 456, "username": "alice"}
}

@app.get("/profile")
def get_profile(session_id: str):
    user = sessions[session_id]  # Сервер помнит
    return {"username": user["username"]}

Минусы:

• Нужно хранить сессии (память, база данных)
• Масштабирование сложное (нужна липкая сессия)
• Когда сервер рестартует, сессии теряются

Stateless (REST/JWT)

# Всё в токене
token = jwt.encode({"user_id": 456, "username": "alice"}, "secret")

@app.get("/profile")
def get_profile(token: str):
    user = jwt.decode(token, "secret")  # Декодируем из токена
    return {"username": user["username"]}

Плюсы:

• Сервер ничего не хранит
• Масштабируется горизонтально
• Безопасно при правильной реализации
• Распределённые системы без проблем

Реальный пример: микросервисная архитектура

# Клиент получает JWT от сервиса аутентификации
login_response = requests.post(
    "https://auth.example.com/login",
    json={"email": "user@example.com", "password": "secret"}
)
token = login_response.json()["access_token"]

# Затем использует токен везде
headers = {"Authorization": f"Bearer {token}"}

# Сервис заказов
orders = requests.get(
    "https://orders.example.com/my-orders",
    headers=headers
)

# Сервис профиля
profile = requests.get(
    "https://profile.example.com/me",
    headers=headers
)

# Каждый микросервис может проверить токен,
# но не хранит state о клиенте

Исключения и оговорки

REST позволяет серверу хранить:

• Постоянные данные о ресурсах (базы данных, файлы)
• Кэши запросов
• Логи

Но не должен хранить:

• Состояние конкретного клиента (сессии)
• История взаимодействия с клиентом
• Временные данные о клиенте

Вывод

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