Архитектура REST

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

История возникновения

Архитектурный стиль REST был впервые описан в 2000 году в докторской диссертации Роя Филдинга (Roy Fielding), одного из создателей протокола HTTP. Филдинг проанализировал эволюцию веб-архитектуры и сформулировал набор ограничений, которые, по его мнению, обеспечивают масштабируемость, производительность и простоту поддержки распределённых систем. До появления REST доминирующим подходом к построению веб-сервисов был SOAP (Simple Object Access Protocol) — протокол, основанный на XML и требующий сложной инфраструктуры. REST предложил более лёгкую и гибкую альтернативу, что привело к его широкому распространению в индустрии, особенно в контексте разработки веб-API (Application Programming Interface).

Основные принципы и ограничения

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

1. Модель «клиент-сервер» (Client-Server)

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

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

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

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

Ответы сервера должны явно указывать, могут ли они быть закэшированы клиентом или промежуточными узлами (прокси, CDN). Кэширование снижает нагрузку на сервер и уменьшает задержки для пользователя. Пометка о кэшировании обычно осуществляется с помощью заголовков HTTP, таких как Cache-Control или Expires.

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

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

• Идентификация ресурсов (Resource Identification): Каждый ресурс (документ, изображение, набор данных) идентифицируется уникальным URI (Uniform Resource Identifier). Например, https://api.example.com/users/123` идентифицирует пользователя с идентификатором 123.
• Манипуляция ресурсами через представления (Manipulation of Resources Through Representations): Клиент взаимодействует не с самим ресурсом, а с его представлением (например, JSON или XML). Клиент может модифицировать или удалять ресурс, отправляя серверу новое представление.
• Самоописываемые сообщения (Self-descriptive Messages): Каждое сообщение (запрос или ответ) содержит достаточно информации для того, чтобы получатель мог его обработать. Например, тип содержимого указывается в заголовке Content-Type, а желаемый формат ответа — в заголовке Accept.
• Гипермедиа как двигатель состояния приложения (HATEOAS — Hypermedia As The Engine Of Application State): Клиент должен динамически узнавать о доступных действиях и переходах через ссылки, включённые в ответы сервера. Это означает, что клиент не должен иметь жёстко закодированных URI для всех операций; он «путешествует» по API, следуя ссылкам, как в веб-сайте. На практике HATEOAS реализуется редко, и большинство популярных RESTful API являются лишь частично соответствующими этому принципу.