Какие правила включает REST-архитектурный стиль?

Правила REST-архитектурного стиля

REST определяется шестью фундаментальными ограничениями, которые должны соблюдаться для соответствия архитектурному стилю.

1. Единообразие интерфейса (Uniform Interface)

Это ключевое ограничение, которое включает четыре принципа:

• Идентификация ресурсов - каждый ресурс имеет уникальный URI

• Манипуляция ресурсами через представления - клиент работает с представлениями ресурсов

• Самодостаточные сообщения - каждое сообщение содержит всю информацию для его обработки

• Гипермедиа как двигатель состояния приложения (HATEOAS) - клиент взаимодействует с API через гиперссылки

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

Каждый запрос от клиента к серверу должен содержать всю необходимую информацию:

• Сервер не хранит состояние клиента между запросами

• Каждый запрос независим и самодостаточен

• Сессионные данные хранятся на клиенте

javascript

// Stateless - каждый запрос содержит всю информацию
// Плохо (stateful):
// Запрос 1: POST /login → сессия создана
// Запрос 2: GET /users → использует сессию

// Хорошо (stateless):
// Запрос 1: POST /login → возвращает токен
// Запрос 2: GET /users + заголовок Authorization: Bearer <token>

3. Кэшируемость (Cacheable)

Ответы должны явно указывать, можно ли их кэшировать:

• Уменьшает нагрузку на сервер

• Улучшает производительность

• Использует HTTP-механизмы кэширования

http

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

4. Клиент-серверная архитектура (Client-Server)

Четкое разделение ответственности:

• Клиент - пользовательский интерфейс и взаимодействие с пользователем

• Сервер - хранение данных, бизнес-логика, безопасность

• Независимая эволюция клиента и сервера

5. Многоуровневая система (Layered System)

Архитектура может состоять из нескольких уровней:

• Клиент не знает, подключен ли он к конечному серверу или промежуточному

• Промежуточные серверы могут обеспечивать балансировку нагрузки, кэширование, безопасность

• Каждый уровень имеет свою ответственность

6. Код по требованию (Code on Demand) - опционально

Сервер может расширять функциональность клиента:

• Передача исполняемого кода (JavaScript, Java applets)

• Уменьшает предварительные знания клиента о сервере

• Редко используется в современных REST API

Вывод: Соблюдение этих шести ограничений обеспечивает создание масштабируемых, производительных и простых в поддержке веб-сервисов, которые могут эволюционировать независимо от клиентов.