REST

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

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

Концепция REST была впервые сформулирована в 2000 году в докторской диссертации Роя Филдинга (Roy Fielding), одного из создателей протокола HTTP и спецификации URI. Филдинг проанализировал архитектуру Всемирной паутины и выделил ключевые принципы, которые обеспечили её масштабируемость, надёжность и производительность. Он предложил использовать эти принципы как основу для проектирования веб-сервисов, в противовес более сложным и менее гибким подходам, таким как SOAP (Simple Object Access Protocol) или CORBA (Common Object Request Broker Architecture).

До появления REST веб-сервисы часто строились на протоколах удалённого вызова процедур (RPC), которые требовали сложной настройки, специфических протоколов и тесной связи между клиентом и сервером. REST предложил более простую и универсальную альтернативу, основанную на стандартных возможностях HTTP.

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

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

1. Модель «клиент-сервер» (Client-Server). Отделение интерфейса пользователя (клиента) от хранилища данных (сервера) позволяет разрабатывать и модифицировать их независимо друг от друга, а также повышает масштабируемость серверной части.
2. Отсутствие состояния (Stateless). Сервер не хранит информацию о состоянии клиента между запросами. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для его обработки (например, данные аутентификации). Это упрощает сервер, повышает его надёжность и облегчает масштабирование.
3. Кэширование (Cacheable). Ответы сервера должны явно или неявно указывать, могут ли они быть закэшированы клиентом или промежуточными прокси-серверами. Кэширование снижает нагрузку на сервер и уменьшает задержки для клиента.
4. Единообразие интерфейса (Uniform Interface). Это ключевое ограничение, которое упрощает и делает прозрачной архитектуру. Оно включает четыре подограничения:

• Идентификация ресурсов (Identification of Resources). Каждый ресурс (например, пользователь, статья, изображение) идентифицируется уникальным URI (Uniform Resource Identifier).
• Манипуляция ресурсами через представления (Manipulation of Resources through Representations). Клиент взаимодействует не с самим ресурсом (например, с записью в базе данных), а с его представлением (например, в формате JSON или XML). Клиент, получив представление, может изменить его и отправить обратно на сервер для обновления ресурса.
• Самодостаточные сообщения (Self-descriptive Messages). Каждое сообщение (запрос или ответ) содержит достаточно информации для того, чтобы быть понятым получателем. Например, в заголовках HTTP указывается тип содержимого (Content-Type), язык (Accept-Language), информация о кэшировании (Cache-Control).
• Гипермедиа как движитель состояния приложения (HATEOAS — Hypermedia As The Engine Of Application State). Клиент взаимодействует с приложением исключительно через гипермедиа-ссылки, предоставленные сервером в ответах. Иными словами, клиенту не нужно заранее знать, какие URI существуют — он «переходит» по ссылкам, которые возвращает сервер. На практике это ограничение часто соблюдается не полностью.

1. Многоуровневая система (Layered System). Архитектура может состоять из нескольких уровней (например, балансировщики нагрузки, прокси-серверы, шлюзы). Клиент обычно не знает, взаимодействует ли он напрямую с конечным сервером или с промежуточным узлом. Это повышает масштабируемость и безопасность.
2. Код по требованию (Code on Demand) (опционально). Сервер может временно расширять функциональность клиента, передавая ему исполняемый код (например, JavaScript-скрипты). Это единственное опциональное ограничение.

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

В контексте REST каждый элемент данных или функциональность рассматривается как ресурс. Ресурс может быть любым объектом, который имеет смысл в предметной области: пользователь, заказ, фотография, погода в городе на текущий момент.

Взаимодействие с ресурсами осуществляется с помощью стандартных методов HTTP, которые интерпретируются как операции CRUD (Create, Read, Update, Delete):

• GET — получение ресурса или списка ресурсов. Не должен изменять состояние сервера (идемпотентен).
• POST — создание нового ресурса. Может также использоваться для выполнения действий, не подходящих под другие методы.
• PUT — полная замена существующего ресурса (или создание, если ресурс не существует). Идемпотентен.
• PATCH — частичное обновление существующего ресурса.
• DELETE — удаление ресурса. Идемпотентен.

Пример работы REST API для управления книгами в библиотеке:

• GET /books — получить список всех книг.
• GET /books/123 — получить книгу с идентификатором 123.
• POST /books — создать новую книгу (данные передаются в теле запроса).
• PUT /books/123 — полностью обновить книгу с идентификатором 123.
• PATCH /books/123 — частично обновить книгу (например, только название).
• DELETE /books/123 — удалить книгу с идентификатором 123.

Форматы представления данных

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

• JSON (JavaScript Object Notation) — лёгкий, читаемый формат, нативный для JavaScript. Стал де-факто стандартом для REST API.
• XML (eXtensible Markup Language) — более строгий и многословный формат, часто используется в корпоративных системах.
• HTML — может использоваться для создания веб-интерфейсов.
• YAML, CSV, изображения — и другие форматы.

Клиент обычно указывает желаемый формат в заголовке Accept, а сервер указывает фактический формат в заголовке Content-Type.

Преимущества и недостатки

Преимущества

• Простота и понятность. REST использует стандартные возможности HTTP и URI, что делает API интуитивно понятными.
• Масштабируемость. Отсутствие состояния и поддержка кэширования позволяют легко масштабировать серверную часть.
• Независимость клиента и сервера. Клиент и сервер могут разрабатываться на разных технологиях и языках программирования.
• Надёжность. Простота архитектуры снижает количество ошибок.
• Широкая поддержка. REST поддерживается практически всеми языками программирования и веб-фреймворками.

Недостатки

• Избыточность. Для выполнения сложных операций, требующих нескольких запросов, может потребоваться много сетевых вызовов (проблема N+1 запроса).
• Сложность с HATEOAS. Полная реализация ограничения HATEOAS часто оказывается сложной и редко применяется на практике, что снижает «самодокументируемость» API.
• Отсутствие строгой спецификации. REST — это набор принципов, а не стандарт, что может приводить к различным интерпретациям (например, разногласия по поводу использования PATCH или POST для частичного обновления).
• Сложность с версионированием. Изменение API может потребовать изменения URI (например, /v1/users -> /v2/users) или заголовков, что не всегда удобно.

Применение

REST является доминирующим архитектурным стилем для создания веб-сервисов и API. Он используется в подавляющем большинстве современных интернет-сервисов: социальные сети, облачные платформы, мобильные приложения, системы электронной коммерции, микросервисные архитектуры. Например, API таких крупных компаний, как Twitter (X), GitHub, Stripe, Amazon Web Services (AWS) и многих других, построены на принципах REST.

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

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

• GraphQL (разработан Facebook, ныне Meta — организация признана экстремистской и запрещена в РФ). Позволяет клиенту запрашивать только те данные, которые ему нужны, в одном запросе, что решает проблему N+1. Однако GraphQL сложнее в реализации и кэшировании.
• gRPC (Google Remote Procedure Call). Использует протокол HTTP/2 и бинарный формат сериализации Protobuf (Protocol Buffers). Обеспечивает высокую производительность и строгую типизацию, но требует генерации кода и менее удобен для веб-браузеров.
• SOAP. Более старый и сложный протокол, основанный на XML. Обеспечивает строгую контрактную систему (WSDL), но считается громоздким и менее гибким по сравнению с REST.

Выбор между 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. Webber, J., Parastatidis, S., & Robinson, I. (2010). REST in Practice: Hypermedia and Systems Architecture. O'Reilly Media.