На каком протоколе основывается REST?

На каком протоколе основывается REST

REST (Representational State Transfer) основывается на **HTTP (HyperText Transfer Protocol)**. Это ключевой момент: REST не является протоколом, а архитектурным стилем, построенным на базе HTTP.

Связь REST и HTTP

REST использует HTTP методы

• GET — получение ресурса (безопасный, идемпотентный)
• POST — создание нового ресурса (не идемпотентный)
• PUT — полное обновление ресурса (идемпотентный)
• PATCH — частичное обновление (не всегда идемпотентный)
• DELETE — удаление ресурса (идемпотентный)
• HEAD — получение заголовков без тела
• OPTIONS — получение информации о доступных методах

REST использует HTTP статус-коды

• 200 OK — успешный запрос
• 201 Created — ресурс создан
• 204 No Content — успех, но нет содержимого
• 400 Bad Request — ошибка в запросе
• 401 Unauthorized — требуется аутентификация
• 403 Forbidden — доступ запрещён
• 404 Not Found — ресурс не найден
• 500 Internal Server Error — ошибка сервера
• 503 Service Unavailable — сервис недоступен

REST использует HTTP заголовки

• Content-Type: application/json — формат данных
• Accept: application/json — ожидаемый формат ответа
• Authorization: Bearer token — аутентификация
• Cache-Control: max-age=3600 — кэширование
• ETag: "12345" — версионирование ресурса
• Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT — дата изменения

Принципы REST на HTTP

1. Client-Server архитектура

• Клиент и сервер разделены
• Они взаимодействуют через HTTP запросы/ответы
• Сервер не хранит контекст клиента (stateless)

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

• Каждый запрос содержит всю необходимую информацию
• Сервер не должен помнить предыдущих запросов клиента
• Всё состояние либо в БД, либо в клиентском приложении
• Упрощает масштабирование (load balancing)

3. Uniform Interface (Единый интерфейс)

• Идентификация ресурсов через URL (URI)
• Манипуляция ресурсов через HTTP методы
• Self-descriptive сообщения (заголовки и тело содержат всю информацию)
• HATEOAS (Hypermedia As The Engine Of Application State)

4. Resource-based URLs

правильно:
GET /api/v1/users — получить всех пользователей
GET /api/v1/users/{id} — получить конкретного пользователя
POST /api/v1/users — создать нового пользователя
PUT /api/v1/users/{id} — обновить пользователя
DELETE /api/v1/users/{id} — удалить пользователя

неправильно:
GET /api/v1/getUsers
GET /api/v1/getUserById?id=123
POST /api/v1/createUser
POST /api/v1/updateUser
GET /api/v1/deleteUser

Почему именно HTTP

1. Универсальность

• HTTP поддерживают все браузеры и операционные системы
• Массовая стандартизация и внедрение
• HTTPS стандарт де-факто для безопасности

2. Простота и ясность

• HTTP хорошо разработан и документирован
• Методы имеют ясную семантику
• Статус-коды покрывают большинство сценариев

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

• HTTP Cache встроен в браузеры и proxies
• Использование Cache-Control, ETag, Last-Modified
• Автоматическая оптимизация производительности

4. Безопасность

• HTTPS с шифрованием TLS/SSL
• Поддержка аутентификации (Basic, Bearer, OAuth)
• CORS для контроля доступа с клиента

5. Состояние и сессии

• HTTP Cookies для хранения session ID
• Но REST рекомендует stateless (token-based вместо cookies)
• Возможность использовать JWT токены

HTTP/1.1 vs HTTP/2 vs HTTP/3

HTTP/1.1 (основной стандарт)

• Долгое время основной протокол для REST
• Проблемы: head-of-line blocking, множественные соединения
• Всё ещё массово используется

HTTP/2 (оптимизация)

• Multiplexing: несколько запросов одновременно
• Server push
• Сжатие заголовков (HPACK)
• Улучшенная производительность

HTTP/3 (QUIC)

• Новый протокол (2022)
• Основан на UDP вместо TCP
• Ещё быстрее, меньше latency
• Постепенное внедрение

REST vs других стилей

REST на HTTP vs SOAP

• SOAP может работать на разных протоколах (HTTP, SMTP, FTP)
• REST почти всегда на HTTP
• REST проще и легче для веб-сервисов

REST vs GraphQL

• GraphQL может работать на HTTP, но это не основной протокол
• GraphQL более гибкий для запроса данных
• REST более RESTful в классическом смысле

REST vs RPC

• RPC фокусируется на вызове функций
• REST фокусируется на ресурсах
• HTTP лучше поддерживает REST парадигму

Практические примеры

Получение пользователя

GET /api/v1/users/42 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGc...
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300
ETag: "abc123"

{
  "id": 42,
  "name": "John Doe",
  "email": "john@example.com",
  "created_at": "2023-01-01T10:00:00Z"
}

Создание пользователя

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...

{
  "name": "Jane Doe",
  "email": "jane@example.com"
}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/v1/users/43

{
  "id": 43,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "created_at": "2023-12-01T15:30:00Z"
}

Обновление пользователя

PUT /api/v1/users/42 HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGc...
If-Match: "abc123"

{
  "name": "John Smith",
  "email": "john.smith@example.com"
}

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "def456"

{
  "id": 42,
  "name": "John Smith",
  "email": "john.smith@example.com",
  "updated_at": "2023-12-01T16:00:00Z"
}

Стандарты и RFC

HTTP/1.1: RFC 7230-7237 HTTP/2: RFC 7540 HTTP Semantics: RFC 9110 REST constraints: опубликовано Roy Fielding в диссертации (2000)

Когда НЕ использовать HTTP для REST

• Real-time приложения (WebSocket вместо долгих polling)
• Streaming больших файлов (может быть лучше FTP или другое)
• Массивные binary данные (хотя HTTP справляется)
• Когда критична минимальная latency (HTTP может быть медленнее)

Итог

REST основывается на HTTP протоколе. REST — это архитектурный стиль, который использует HTTP методы (GET, POST, PUT, DELETE), статус-коды, заголовки и URL для создания масштабируемых веб-сервисов. HTTP обеспечивает универсальность, безопасность, кэширование и простоту реализации REST API. Это одна из главных причин популярности REST для создания веб-сервисов.