Какие знаешь требования REST?

Требования архитектурного стиля REST (Representational State Transfer)

REST — это архитектурный стиль для распределенных систем, предложенный Роем Филдингом в 2000 году. Его ключевые требования, или ограничения (constraints), направлены на создание масштабируемых, надежных и простых в поддержке веб-сервисов. Вот шесть основных требований, которым должна соответствовать система, чтобы считаться RESTful.

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

Это фундаментальное разделение ответственности. Клиент и сервер развиваются независимо. Сервер предоставляет ресурсы, а клиент управляет их представлением и взаимодействием с пользователем. Это повышает портативность клиентского кода (например, веб-приложение, мобильное приложение) и упрощает масштабирование серверных компонентов.

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

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

• Преимущество: Упрощает серверную логику, повышает надежность и упрощает горизонтальное масштабирование.
• Пример: Аутентификация через JWT-токен, который клиент отправляет в заголовке Authorization каждого запроса.

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

Ответы сервера должны явно или неявно помечаться как кэшируемые или нет. Это позволяет клиентам и промежуточным прокси кэшировать данные, что значительно снижает нагрузку на сервер, уменьшает задержки и повышает производительность. Используются стандартные HTTP-заголовки, такие как Cache-Control, Expires, ETag.

HTTP/1.1 200 OK
Cache-Control: public, max-age=3600
Content-Type: application/json

{"id": 123, "name": "Product A"}

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

Это центральный принцип REST, который подразделяется на несколько ключевых ограничений:

• Идентификация ресурсов: Каждый ресурс (например, пользователь, заказ) однозначно идентифицируется URI (Uniform Resource Identifier).

    *   `GET /api/users/123`

• Манипуляция ресурсами через представления: Клиент работает с ресурсом через его представление (например, JSON или XML). Получив представление, клиент потенциально обладает достаточной информацией для модификации или удаления ресурса.
• Самодостаточные сообщения: Каждое сообщение (запрос/ответ) содержит достаточно информации для его обработки (связано с Stateless).
• HATEOAS (Hypermedia as the Engine of Application State): Клиент взаимодействует с приложением через гипермедиа (ссылки), динамически предоставляемые сервером в ответах. Это делает API открытым для изменений и более обнаруживаемым.

{
  "order": {
    "id": 456,
    "total": 99.99,
    "status": "processing"
  },
  "_links": {
    "self": { "href": "/api/orders/456" },
    "cancel": { "href": "/api/orders/456", "method": "DELETE" },
    "payment": { "href": "/api/payments/order/456" }
  }
}

5. Слоистая система (Layered System)

Архитектура может состоять из множества иерархических слоев (прокси, шлюзы, балансировщики нагрузки). Клиент не знает, подключен ли он напрямую к конечному серверу или к промежуточному узлу. Это улучшает масштабируемость и безопасность, позволяет делегировать функции (кэширование, безопасность) специализированным слоям.

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

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

Практические принципы для RESTful API

Помимо архитектурных ограничений, на практике следуют общепринятым соглашениям:

• Использование HTTP-методов по назначению:

    *   `GET` — получение ресурса.
    *   `POST` — создание нового ресурса.
    *   `PUT` — полное обновление ресурса.
    *   `PATCH` — частичное обновление ресурса.
    *   `DELETE` — удаление ресурса.

• Использование HTTP-статус кодов: 200 OK, 201 Created, 400 Bad Request, 404 Not Found, 500 Internal Server Error.
• Структурированные URI: Использование существительных во множественном числе для коллекций (/users), иерархии (/users/123/orders), фильтрация через query-параметры (/users?active=true).

Как QA-инженер, я проверяю соблюдение этих требований: тестирую корректность кодов ответа, идемпотентность методов (GET, PUT, DELETE), работу с кэшированием, обработку ошибок, безопасность stateless-аутентификации, а также удобство и предсказуемость API для потребителей. Нарушение этих принципов (например, использование GET для изменения состояния) ведет к созданию хрупкого, небезопасного и плохо масштабируемого API.