Команда REST

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

История и происхождение

Архитектурный стиль REST был впервые описан в 2000 году в докторской диссертации Роя Филдинга (Roy Fielding), одного из создателей протокола HTTP и спецификации URI. Диссертация называлась «Architectural Styles and the Design of Network-based Software Architectures». Филдинг анализировал существующие веб-протоколы и предложил REST как абстрактную модель, которая объясняет, почему Всемирная паутина работает так, как работает, и как её можно использовать для построения масштабируемых и надёжных распределённых систем.

До появления REST доминирующим подходом для построения веб-сервисов был SOAP (Simple Object Access Protocol) — протокол, основанный на XML и требующий строгих контрактов (WSDL). REST, в отличие от SOAP, предлагал более простой, лёгкий и гибкий подход, основанный на стандартных HTTP-методах и форматах данных. Благодаря своей простоте и эффективности REST быстро стал популярным, особенно в эпоху развития мобильных приложений и облачных вычислений, и сегодня является стандартом де-факто для разработки публичных API.

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

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

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

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

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

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

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

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

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

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

• Идентификация ресурсов: Каждый ресурс (например, пользователь, статья, изображение) идентифицируется уникальным URI (Uniform Resource Identifier). Ресурсы — это концептуальные сущности, а не их представления.
• Манипуляция ресурсами через представления: Клиент получает от сервера представление ресурса (например, в формате JSON или XML), которое содержит достаточно информации для его изменения или удаления. Клиент не знает, как сервер хранит данные.
• Самодостаточные сообщения: Каждое сообщение (запрос или ответ) содержит всю информацию, необходимую для его обработки. Например, в ответе на запрос о пользователе могут быть ссылки (hypermedia links) на его заказы или друзей.
• HATEOAS (Hypermedia as the Engine of Application State): Клиент взаимодействует с приложением исключительно через гипермедиа-ссылки, предоставляемые сервером в ответах. Клиент не должен иметь предварительных знаний о структуре API или URI. Фактически, сервер сообщает клиенту, какие действия возможны в данный момент. Это самое сложное для реализации ограничение, и на практике его часто опускают.

5. Многоуровневая система (Layered System)

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

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

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

Ресурсы и HTTP-методы

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

Для манипуляции ресурсами используются стандартные HTTP-методы, которые в RESTful API соответствуют операциям CRUD (Create, Read, Update, Delete):

• GET: Получение представления ресурса или коллекции ресурсов. Безопасный и идемпотентный метод (не изменяет состояние сервера).
• POST: Создание нового ресурса. Неидемпотентный (повторный вызов приведёт к созданию нескольких ресурсов).
• PUT: Полная замена существующего ресурса. Идемпотентный.
• PATCH: Частичное обновление существующего ресурса. Идемпотентный.
• DELETE: Удаление ресурса. Идемпотентный.

Форматы данных

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

• JSON (JavaScript Object Notation): Легкий, читаемый и широко поддерживаемый формат, ставший стандартом для REST API.
• XML (eXtensible Markup Language): Более громоздкий и строгий формат, часто используется в корпоративных системах.
• YAML (YAML Ain't Markup Language): Формат, ориентированный на удобство чтения человеком, часто используется в конфигурационных файлах.
• HTML: Для веб-сервисов, возвращающих готовые HTML-страницы.
• Изображения, видео, бинарные файлы: Для передачи медиа-контента.

Коды состояния HTTP

Для информирования клиента о результате выполнения запроса используются стандартные HTTP-коды состояния:

• 200 OK: Запрос выполнен успешно.
• 201 Created: Ресурс успешно создан (обычно в ответ на POST).
• 204 No Content: Запрос выполнен успешно, но тело ответа пусто (обычно в ответ на DELETE).
• 400 Bad Request: Некорректный запрос от клиента (например, неверный синтаксис).
• 401 Unauthorized: Необходима аутентификация.
• 403 Forbidden: Доступ запрещён (даже при аутентификации).
• 404 Not Found: Ресурс не найден.
• 500 Internal Server Error: Внутренняя ошибка сервера.

Применение и значение

REST широко используется для построения публичных и внутренних API веб-сервисов, мобильных приложений и микросервисных архитектур. Его простота, масштабируемость и совместимость с HTTP-инфраструктурой (кеширующие прокси, балансировщики нагрузки) сделали его доминирующим подходом в современной веб-разработке. Практически все крупные интернет-компании (Google, Twitter, GitHub, Amazon, VK, Яндекс) предоставляют RESTful API для доступа к своим сервисам.

Критика и альтернативы

Несмотря на широкую распространённость, REST подвергается критике по нескольким причинам:

• Сложность HATEOAS: Реализация полного HATEOAS-интерфейса сложна и редко применяется на практике. Многие API, называющие себя RESTful, на самом деле являются лишь «REST-подобными» (RESTish), не соблюдая это ограничение.
• Избыточность данных: При запросе коллекции ресурсов клиент часто получает больше данных, чем ему нужно (over-fetching). Для решения этой проблемы используются такие техники, как GraphQL или частичные ответы (sparse fieldsets).
• Проблема с версионированием: Изменение структуры ресурса может привести к поломке клиентов. Существуют разные подходы к версионированию (через URI, заголовки), но единого стандарта нет.
• Неэффективность для сложных запросов: Для получения данных из нескольких связанных ресурсов (например, пользователь + его заказы + товары в заказах) может потребоваться несколько запросов (N+1 problem).

Альтернативами REST являются:

• GraphQL: Язык запросов, разработанный Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ), позволяющий клиенту запрашивать только необходимые данные и получать их в одном запросе.
• gRPC: Высокопроизводительный фреймворк от Google, основанный на протоколе HTTP/2 и Protocol Buffers, часто используемый в микросервисных архитектурах.
• SOAP: Более старый и строгий протокол, всё ещё используемый в некоторых корпоративных и финансовых системах.

Интересные факты

• Термин «REST» был придуман Роем Филдингом, который также является автором спецификации HTTP/1.1.
• Несмотря на то, что REST часто ассоциируется с JSON, Филдинг в своей диссертации не упоминал JSON. Он рассматривал HTML и XML как основные форматы представления.
• Большинство API, которые называют себя «RESTful», на самом деле не соблюдают ограничение HATEOAS и являются просто «HTTP API» или «REST-подобными».

Источники

1. Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine.
2. Fielding, R. T., & Taylor, R. N. (2002). Principled design of the modern Web architecture. ACM Transactions on Internet Technology (TOIT), 2(2), 115-150.
3. Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly Media.
4. Masse, M. (2011). REST API Design Rulebook. O'Reilly Media.