Какие характеристики отличают REST API от других подходов?

REST (Representational State Transfer) — это архитектурный стиль, а не протокол или стандарт. Он определяет набор ограничений, которые, будучи применены к проектированию системы, приводят к созданию масштабируемых, производительных и простых в поддержке веб-сервисов.

Ключевые принципы (ограничения) REST

• Единообразие интерфейса (Uniform Interface): Это фундаментальный принцип. Ресурсы идентифицируются через URI, а взаимодействие с ними происходит с помощью стандартных HTTP-методов. Ресурсы отделены от их представлений (например, JSON или XML), и клиенты могут манипулировать ресурсами через эти представления.
• Отсутствие состояния (Stateless): Сервер не хранит состояние сессии клиента между запросами. Каждый запрос должен содержать всю необходимую информацию для его понимания и выполнения. Это повышает надёжность и упрощает горизонтальное масштабирование.
• Кэшируемость (Cacheability): Ответы сервера должны явно указывать, можно ли их кэшировать и насколько долго. Это значительно снижает нагрузку на сервер и улучшает производительность.
• Клиент-серверная архитектура: Чёткое разделение обязанностей позволяет клиентским и серверным компонентам развиваться независимо.
• Слоистая система (Layered System): Архитектура может состоять из нескольких слоёв (прокси, балансировщики, шлюзы), при этом клиент не знает, с каким именно слоем он взаимодействует.
• Код по требованию (Code on Demand, опционально): Сервер может временно расширять функциональность клиента, передавая исполняемый код (например, JavaScript).

Отличия от других подходов

Главные отличия от, например, SOAP или RPC-подобных API (включая GraphQL) заключаются в философии. REST ориентирован на ресурсы и стандартные HTTP-методы, в то время как SOAP — это протокол, ориентированный на операции (действия) и строгие контракты (WSDL). GraphQL, в свою очередь, предоставляет клиенту гибкость в запрашиваемых данных, но не обязательно следует всем ограничениям REST, таким как кэширование на уровне HTTP.

Пример RESTful взаимодействия

// Получение списка пользователей (ресурс: /users)
GET /api/users HTTP/1.1
Host: example.com
Accept: application/json

// Создание нового пользователя
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com"
}

// Обновление пользователя с id=123
PUT /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Alice Smith",
  "email": "alice.smith@example.com"
}

// Удаление пользователя с id=123
DELETE /api/users/123 HTTP/1.1
Host: example.com

В этом примере видно, как URI (/api/users) идентифицирует ресурс «пользователи», а HTTP-метод определяет действие. Ответы могут иметь разные коды состояния (200 OK, 201 Created, 404 Not Found), что также является частью единого интерфейса.

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