Назови признаки REST FULL

Основные принципы (Constraints) RESTful архитектуры

Полноценный RESTful API (или RESTful сервис) следует набору архитектурных ограничений, сформулированных Роем Филдингом в его диссертации. Эти ограничения обеспечивают масштабируемость, производительность и простоту поддержки. Вот ключевые признаки:

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

• Разделение ответственности: Клиент отвечает за пользовательский интерфейс и взаимодействие с пользователем, сервер — за обработку данных, хранение и бизнес-логику.
• Независимая эволюция: Клиент и сервер могут развиваться независимо друг от друга, при условии, что контракт (API) между ними сохраняется.

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

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

• Пример: Аутентификация через токен (например, JWT), который передается в заголовке каждого запроса (Authorization: Bearer <token>), вместо хранения сессии на сервере.
• Преимущества: Масштабируемость, надежность, простота кэширования.

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

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

• Реализация: Через стандартные HTTP-заголовки, такие как Cache-Control, Expires, ETag, Last-Modified.

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

{"id": 1, "name": "Product"}

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

Фундаментальный принцип, который делает архитектуру REST отличимой. Он включает несколько подпринципов:

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

    *   `GET /api/users/123`

• Манипуляция ресурсами через представления (Resource Manipulation through Representations): Клиент работает с ресурсом через его представление (например, JSON или XML). Получив представление, клиент обладает достаточной информацией для модификации или удаления ресурса (при наличии прав).
• Самодостаточные сообщения (Self-descriptive Messages): Каждое сообщение (запрос/ответ) содержит достаточно информации для его обработки. Это достигается за счет использования стандартных HTTP-методов, медиатипов (MIME types) и кодов состояния.
• Гипермедиа как двигатель состояния приложения (HATEOAS - Hypermedia As The Engine Of Application State): Это самый строгий и часто не полностью реализуемый принцип. Ответы сервера должны содержать гиперссылки, определяющие возможные последующие действия с ресурсом или связанными ресурсами. Клиент "перемещается" по API, следуя этим ссылкам, а не конструируя URI самостоятельно по шаблону.

{
  "id": 123,
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "_links": {
    "self": { "href": "/api/users/123" },
    "orders": { "href": "/api/users/123/orders" },
    "update": { "href": "/api/users/123", "method": "PUT" },
    "delete": { "href": "/api/users/123", "method": "DELETE" }
  }
}

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

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

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

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

---

Ключевые практические признаки RESTful HTTP API

На практике, говоря о REST API, часто подразумевают соблюдение следующих производных от принципов Филдинга правил:

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

    *   `GET` — получение ресурса или коллекции (без побочных эффектов).
    *   `POST` — создание нового ресурса.
    *   `PUT` — полное обновление ресурса (идемпотентная операция).
    *   `PATCH` — частичное обновление ресурса.
    *   `DELETE` — удаление ресурса (идемпотентная операция).

• Использование HTTP-кодов состояния для индикации результата:

    *   `2xx` — Успех (200 OK, 201 Created, 204 No Content).
    *   `3xx` — Перенаправление.
    *   `4xx` — Ошибка клиента (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
    *   `5xx` — Ошибка сервера (500 Internal Server Error).

• Ресурсно-ориентированные URL (Resource-oriented URLs): URI структурированы вокруг ресурсов (существительных), а не действий (глаголов).

    *   **Не RESTful**: `/api/getUser?id=1` или `/api/updateUser`.
    *   **RESTful**: `GET /api/users/1` или `PUT /api/users/1`.

• Использование стандартных форматов данных: Как правило, JSON (реже XML) для представления ресурсов, с указанием типа содержимого в заголовке Content-Type.

Важное замечание: В современной индустрии термин "REST API" часто применяется к HTTP API, которые следуют лишь базовым принципам (ресурсы, HTTP-методы, коды состояния), но не реализуют полный HATEOAS. Такие API иногда называют REST-like или HTTP API. Однако соблюдение Stateless принципа, правильное использование HTTP-методов и кодов состояния уже является сильным признаком RESTful подхода.