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

REST (от англ. Representational State Transfer — «передача репрезентативного состояния») — это архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой набор согласованных ограничений (констрейнтов), которые определяют, как сервер и клиент обмениваются данными, как идентифицируются ресурсы и как управляется состояние сессии. В отличие от протокола или стандарта, REST является парадигмой проектирования веб-сервисов, наиболее известной реализацией которой являются API, работающие поверх протокола HTTP. Основополагающий принцип REST — каждый элемент системы (документ, изображение, запись в базе данных) рассматривается как ресурс, имеющий уникальный идентификатор (URI), а манипуляции с ним осуществляются через стандартные методы протокола (например, GET, POST, PUT, DELETE). Архитектура REST была сформулирована Роем Филдингом в его докторской диссертации в 2000 году и с тех пор стала доминирующим подходом для построения публичных и внутренних API в веб-разработке.

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

Концепция REST возникла как результат анализа эволюции Всемирной паутины (World Wide Web). В середине 1990-х годов Рой Филдинг, один из главных авторов спецификаций HTTP/1.0 и HTTP/1.1, а также соавтор протокола URI, начал систематизировать принципы, которые сделали Web масштабируемой и устойчивой распределённой системой.

В 2000 году в своей диссертации «Architectural Styles and the Design of Network-based Software Architectures» Филдинг ввёл термин REST и описал его как набор архитектурных ограничений. Он противопоставил REST более ранним подходам, таким как RPC (Remote Procedure Call), которые требовали жёсткой привязки к конкретным методам и протоколам. Филдинг показал, что именно соблюдение принципов REST (кэширование, единообразие интерфейса, отсутствие состояния на сервере) позволило Web расти до глобальных масштабов.

После публикации диссертации REST постепенно начал вытеснять SOAP (Simple Object Access Protocol) и другие протоколы в сфере веб-сервисов. К середине 2000-х годов крупные компании, такие как Amazon, eBay и Flickr, начали предоставлять публичные RESTful API. Это способствовало популяризации архитектуры, и к 2010-м годам REST стал стандартом де-факто для проектирования API в веб-разработке.

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

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

Клиент-серверная архитектура (Client-Server)

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

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

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

Кэширование (Cache)

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

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

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

Идентификация ресурсов: Каждый ресурс имеет уникальный URI (например, /users/123). Сам URI не описывает, что нужно сделать с ресурсом — это определяет метод HTTP.
Манипуляция ресурсами через представления: Клиент получает не сам ресурс, а его представление (например, JSON, XML, HTML). Если клиент имеет права, он может отправить новое представление для изменения ресурса.
Самоописываемые сообщения: Каждое сообщение (запрос и ответ) содержит достаточно информации для его обработки. В заголовках указывается тип данных (Content-Type), метод, параметры кэширования и т.д.
HATEOAS (Hypermedia as the Engine of Application State): Клиент должен переходить по состояниям приложения только через гипермедиа-ссылки, предоставленные сервером в ответах. На практике это означает, что ответ API содержит не только данные, но и ссылки на связанные ресурсы (например, при получении заказа возвращается ссылка на его оплату). Это делает API самодокументируемым и менее хрупким.

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

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

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

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

Методы HTTP в REST

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

Метод HTTP	Действие	Пример для ресурса `/users/123`
GET	Получить представление ресурса	`GET /users/123` — возвращает данные пользователя
POST	Создать новый ресурс	`POST /users` — создаёт нового пользователя, данные в теле запроса
PUT	Полностью заменить ресурс	`PUT /users/123` — заменяет все поля пользователя
PATCH	Частично обновить ресурс	`PATCH /users/123` — обновляет только переданные поля
DELETE	Удалить ресурс	`DELETE /users/123` — удаляет пользователя

Идемпотентность (повторное выполнение даёт тот же результат) и безопасность (не изменяет состояние сервера) являются важными свойствами этих методов. GET, PUT, DELETE — идемпотентны; POST — не идемпотентен; GET — безопасен.

Ресурсы и URI

В REST ресурсы представляют собой любые сущности предметной области: пользователи, заказы, товары, статьи. Ресурсы идентифицируются с помощью URI (Uniform Resource Identifier). Хороший RESTful API использует существительные во множественном числе для коллекций и иерархические пути:

GET /users — список пользователей
GET /users/123 — конкретный пользователь
GET /users/123/orders — заказы пользователя 123
GET /users/123/orders/5 — заказ 5 пользователя 123

Важно, что URI не должны содержать глаголов (например, /getUser или /createOrder), так как действие определяется методом HTTP.

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

Сервер может возвращать ресурс в различных форматах (представлениях). Наиболее распространённые форматы:

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

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

Примеры RESTful API

REST-архитектура используется повсеместно. Крупные примеры:

API GitHub — позволяет получать информацию о репозиториях, пользователях, коммитах. Использует JSON, HATEOAS (частично), стандартные методы HTTP.
API Twitter (X) — предоставляет доступ к твитам, пользователям, трендам. Работает через REST, хотя в последние годы компания активно внедряет GraphQL.
API Google Drive — позволяет управлять файлами и папками, используя RESTful принципы.
API Яндекс.Карт и API ВКонтакте — российские сервисы, построившие свои публичные интерфейсы на основе REST (с некоторыми особенностями).

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

Несмотря на широкое распространение, REST не лишён недостатков. Основные претензии:

Избыточность данных: Часто клиент получает больше данных, чем ему нужно (overfetching). Например, для отображения имени пользователя приходится запрашивать весь объект.
Множественные запросы: Для получения связанных данных (например, пользователя и его последних заказов) требуется несколько запросов, что увеличивает задержки.
Сложность HATEOAS: На практике HATEOAS редко реализуется полностью, так как требует сложной логики на сервере и клиенте. Большинство API являются RESTful только в смысле использования методов HTTP и URI, но не следуют гипермедиа-принципу.
Отсутствие строгой типизации: В отличие от SOAP с WSDL, REST не имеет встроенного механизма для описания контракта API. Для этого используются сторонние спецификации, такие как OpenAPI (Swagger).

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

GraphQL — язык запросов, разработанный Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ), позволяющий клиенту точно указать, какие поля нужны, и получать связанные данные в одном запросе.
gRPC — высокопроизводительный фреймворк от Google, использующий Protocol Buffers и HTTP/2. Ориентирован на микросервисную архитектуру.
SOAP — более старый протокол, использующий XML и строгую типизацию. Применяется в финансовом секторе и телекоммуникациях, где требуется высокая надёжность и сложные транзакции.

Применение в России

REST-архитектура широко применяется в российской IT-индустрии. Государственные информационные системы (ГИС), такие как портал «Госуслуги», используют RESTful API для взаимодействия с банками, ведомствами и мобильными приложениями. Крупные российские компании (Сбер, Яндекс, VK, Т-Банк) предоставляют REST API для разработчиков. Внутренние системы предприятий также строятся на REST, особенно в микросервисной архитектуре. При проектировании REST API в России часто руководствуются методическими рекомендациями Минцифры и стандартами OpenAPI.

Источники

Fielding, R. T. (2000). «Architectural Styles and the Design of Network-based Software Architectures». Doctoral dissertation, University of California, Irvine.
Fielding, R. T., & Taylor, R. N. (2002). «Principled design of the modern Web architecture». ACM Transactions on Internet Technology.
Richardson, L., & Ruby, S. (2007). «RESTful Web Services». O'Reilly Media.
Masse, M. (2011). «REST API Design Rulebook». O'Reilly Media.
Спецификация HTTP/1.1 (RFC 7230-7235). Internet Engineering Task Force.
OpenAPI Specification (версия 3.0). OpenAPI Initiative, Linux Foundation.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →