Основы REST

Этот материал представляет объяснение термина REST, включающее экзаменационные вопросы, практический пример и справочные материалы.

В двух словах

REST — это стиль архитектуры для распределённых систем на основе HTTP. Ресурсы адресуются через URI, манипулируются методами и передаются в виде представлений. Цель: слабая связанность, масштабируемость и кэширование.

Краткое техническое описание

REST определяет шесть constraints:

• Client-Server
• Statelessness
• Cache-Fähigkeit
• Uniform Interface
• Layered
• опционально Code on Demand

Ресурсы — это бизнес-объекты (например, /orders/42). Представления переносят состояние (JSON/XML) и согласовываются через Accept и Content-Type.

Семантика методов:

• GET: безопасный и идемпотентный
• POST: не идемпотентный
• PUT: идемпотентный
• PATCH: не обязательно идемпотентный
• DELETE: идемпотентный

Статус-коды сигнализируют об успехе или ошибке (200/201/204/400/401/403/404/409/500). HATEOAS использует ссылки в представлениях для создания “обнаружимых” рабочих потоков. Кэширование использует Cache-Control, ETag, If-None-Match.

Ключевые моменты для экзамена

• Ресурсо-ориентированный дизайн URI (без глаголов в пути)
• Семантика safe/idempotent методов
• Правильные статус-коды (Location при 201)
• Idempotency Key для POST (если требуется)
• Security: TLS, OAuth/OIDC/JWT, CORS, Rate Limiting
• Экономичность: слабая связанность
• Документация: OpenAPI и каталог ошибок

Основные компоненты

1. Ресурс и дизайн URI
2. Представления и медиа-типы
3. Семантика методов
4. Статус-коды и заголовки
5. Content Negotiation
6. Кэширование (ETag)
7. Security
8. Версионирование
9. Observability
10. Тесты (Contract/API)

Практический пример (Orders + HATEOAS)

{
  "id": 42,
  "status": "created",
  "links": [
    { "rel": "self", "href": "/orders/42" },
    { "rel": "confirm", "method": "POST", "href": "/orders/42/confirm" }
  ]
}

Преимущества и недостатки

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

• Взаимодействие через стандарты
• Слабая связанность
• Хорошая масштабируемость благодаря statelessness
• Эффективное кэширование

Недостатки

• Возможны overfetching/underfetching
• Сложные операции записи требуют стратегий идемпотентности
• HATEOAS часто реализуется непоследовательно

Типичные экзаменационные вопросы (с кратким ответом)

1. Какие REST-constraints существуют? Client-Server, Stateless, Cache, Uniform Interface, Layered, опционально Code on Demand.
2. PUT vs PATCH с точки зрения идемпотентности? PUT идемпотентный, PATCH не обязательно.
3. Как работают ETag и условные запросы? Клиент отправляет If-None-Match, сервер отвечает 304 или возвращает новое содержимое.

Развёрнутый ответ

REST — это больше, чем “JSON поверх HTTP”: constraints и семантика методов имеют решающее значение. Чистые объекты ошибок, версионирование и observability делают API удобным в поддержке.

Стратегия обучения

1. Анализируйте публичные API и сопоставляйте их с constraints.
2. Разработайте модель ресурсов (URI/методы/статус-коды).
3. Практикуйте таблицу семантики методов (safe/idempotent).
4. Избегайте глаголов в пути.

Основные источники

1. https://roy.gbiv.com/untangled
2. https://www.rfc-editor.org/rfc/rfc9110
3. https://learn.microsoft.com/azure/architecture/best-practices/api-design