APIСтандартизация
тема 1
Открыть слайдами →

9REST — архитектурный стиль

REST не является языком программирования, библиотекой или форматом JSON.

REST (Representational State Transfer) — архитектурный стиль для распределённых систем. Его сформулировал Рой Филдинг в диссертации 2000 года.

Стиль задан набором архитектурных ограничений. Если система их соблюдает, клиент и сервер можно развивать относительно независимо: менять интерфейс, не трогая базу, или переносить сервер, не переписывая клиентов.

REST = набор архитектурных ограничений

ОграничениеСуть
Client–Serverразделение обязанностей клиента и сервера
Statelessкаждый запрос содержит всё нужное для обработки
Cacheableответ сообщает, можно ли его повторно использовать
Layered Systemмежду клиентом и сервером могут быть промежуточные слои
Uniform Interfaceединые правила взаимодействия с любым ресурсом
Code on Demandнеобязательное: сервер может передать клиенту исполняемый код

Следующие пять слайдов разбирают обязательные ограничения.

10Клиент и сервер имеют разные обязанности

Клиент отвечает за использование данных. Сервер отвечает за их предоставление и изменение.

React / Mobile App→HTTP→FastAPI

Благодаря этому разделению изменение интерфейса мобильного приложения не требует изменения базы данных сервера. А перенос базы на другую СУБД не требует обновлять приложение у пользователей.

ClientServer
UIBusiness logic
NavigationDatabase
DisplayAuthorization

11Каждый запрос должен быть самодостаточным

Сервер не должен рассчитывать на то, что предыдущий HTTP request объяснил следующий. Запрос сам содержит необходимые данные.

Поэтому токен доступа передаётся в каждом защищённом запросе:

заголовок каждого запроса
Authorization: Bearer ey...

Не следует строить контракт вида «сначала вызови A, сервер это запомнит, потом вызови B», если состояние можно явно передать в запросе.

Так не надо
сначала вызови A
потом сервер запомнит это
после этого вызови B
Так надо
B + всё, что нужно
    для его обработки
  1. REQUEST 1 → SERVER
  2. REQUEST 2 → SERVER
  3. REQUEST 3 → SERVER
  4. Каждый request самодостаточенлюбой из них может обработать любой экземпляр сервера

12Ответ может иметь правила кэширования

HTTP позволяет серверу сообщить, можно ли повторно использовать ранее полученный response.

заголовок ответа
Cache-Control: max-age=300

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

Кэширование — часть архитектуры HTTP API, а не особенность Swagger.

  1. CLIENT
  2. CACHEсохранённый response
  3. SERVERполучает запрос, только если в кэше нет годного ответа

13Между клиентом и сервером могут быть промежуточные слои

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

Каждый слой решает свою задачу:

СлойЗадача
CDNотдаёт кэшированные ответы ближе к пользователю
API Gatewayпроверяет токены, ограничивает частоту запросов
Load Balancerраспределяет запросы между экземплярами сервиса

Инфраструктуру можно менять без изменения клиентского контракта.

  1. CLIENT
  2. CDN
  3. API GATEWAY
  4. LOAD BALANCER
  5. FASTAPI

14Одинаковые правила взаимодействия

REST стремится к единообразному интерфейсу: с любым ресурсом работают по одним и тем же правилам.

Элемент HTTPЧто делает
URIидентифицирует ресурс
HTTP methodзадаёт действие
status codeсообщает результат
representationпередаёт состояние ресурса, например JSON

Поэтому вместо отдельной команды deleteTicket() используется стандартная HTTP-семантика:

DELETE /tickets/42
правило

RESOURCE + HTTP METHOD = OPERATION

Клиент, который умеет удалять заказ в одном API, по той же схеме удалит обращение в другом.

15Не каждый JSON API полностью RESTful

На практике термин «REST API» часто применяют к любому HTTP API, которое использует ресурсы, методы и JSON.

Обычно так называют API, которое использует:

  • ресурсы;
  • HTTP methods;
  • HTTP status codes;
  • JSON;
  • stateless-взаимодействие.

Полное соответствие всем ограничениям REST, включая hypermedia (ссылки на следующие действия прямо в ответе), встречается значительно реже.

пересечение

HTTP API ∩ REST principles

Для нашей дисциплины важно не спорить о названии, а понимать, какие конкретно правила выполняет API.

Кадр крупным планом