REST (Representational State Transfer)¶

REST — это архитектурный стиль для построения веб-сервисов, основанный на принципах взаимодействия через HTTP и представление ресурсов.

REST не является протоколом или стандартом — это набор ограничений и рекомендаций, которые делают API понятным, масштабируемым и кроссплатформенным.

Основные принципы REST¶

1.Клиент-серверная архитектура¶

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

2.Отсутствие состояния (statelessness)¶

Каждый HTTP-запрос должен быть самодостаточным.
Сервер не хранит состояние клиента между запросами.
Все необходимые данные (например, токен авторизации) должны передаваться в каждом запросе.

3.Кеширование¶

Ответы сервера могут быть кешируемыми, если они не изменяются часто.
Это позволяет снизить нагрузку и повысить производительность.

4.Единый интерфейс (uniform interface)¶

Взаимодействие с ресурсами всегда происходит через единые правила.
Ресурсы идентифицируются через URL.
Операции выполняются с помощью стандартных HTTP-методов:
- GET – получить ресурс (чтение данных). Является безопасным и идемпотентным (выполнение запроса не изменяет состояние сервера и при повторении дает тот же результат).
- POST – создать новый ресурс. Не является ни безопасным, ни идемпотентным: повторный POST может создавать дубли (например, два одинаковых заказа).
- PUT – полное обновление ресурса (замена). Не безопасен, но идемпотентен: несколько одинаковых PUT приведут к одному и тому же итоговому состоянию ресурса.
- PATCH – частичное обновление ресурса. Не идемпотентен (если не спроектирован специально), так как повторный PATCH может применить изменения повторно.
- DELETE – удаление ресурса. Тоже не безопасен, но практически идемпотентен (удаление уже удаленного ресурса обычно возвращает код 404 без дополнительных эффектов)

5.Идентификация ресурсов через URI¶

Ресурсы (например, пользователи, заказы) представлены уникальными адресами:

GET /users/42
DELETE /orders/1001

6.Представление ресурса (Representation)¶

Ресурс может передаваться в разных форматах: JSON (чаще всего), XML и др.
Клиент может запрашивать нужный формат через заголовок Accept.

7.Код по требованию (необязательный принцип)¶

Сервер может передавать клиенту исполняемый код (например, JavaScript).
Этот принцип редко используется на практике.

Пример REST-запроса¶

GET /api/users/10 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer abc123

Ответ:

{
  "id": 10,
  "name": "Alice",
  "email": "alice@example.com"
}

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

Простота и понятность.
Использование стандартных HTTP-методов.
Масштабируемость и гибкость.
Поддержка кэширования и разграничения клиент-серверной логики.

Полезные ресурсы:¶

Источники:

API межсистемной интеграции: REST, SOAP, gRPC и GraphQL

Дополнительные материалы: