Representational State Transfer¶

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

¶История

Архитектурный стиль REST был введён в 2000 году в докторской диссертации Роя Филдинга (Roy Fielding), одного из создателей протокола HTTP. Филдинг, анализируя развитие веба, стремился формализовать принципы, которые сделали Всемирную паутину успешной и масштабируемой. В диссертации он описал REST как архитектурную модель, которая объясняет, как работают веб-серверы, браузеры и прокси-серверы, и предложил использовать её для проектирования новых сетевых приложений.

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

¶Основные принципы и ограничения (констрейнты)

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

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

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

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

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

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

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

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

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

• Идентификация ресурсов (Identification of Resources): Каждый ресурс (документ, изображение, пользователь, заказ) идентифицируется уникальным URI (Uniform Resource Identifier). Например, /users/123 — это идентификатор пользователя с ID 123.
• Манипуляция ресурсами через представления (Manipulation of Resources through Representations): Клиент взаимодействует не с самим ресурсом (например, с базой данных), а с его представлением (например, JSON-объектом или HTML-страницей). Если клиент получает представление ресурса, он может изменить его и отправить обратно на сервер для обновления.
• Самоописывающие сообщения (Self-descriptive Messages): Каждое сообщение (запрос или ответ) содержит всю информацию, необходимую для его обработки. Например, HTTP-заголовок Content-Type указывает формат данных (application/json, text/html), а Accept — какой формат ожидает клиент.
• Гипермедиа как движитель состояния приложения (HATEOAS — Hypermedia As The Engine Of Application State): Клиент переходит между состояниями приложения исключительно через гиперссылки, предоставленные сервером в ответах. Это означает, что клиент не должен знать заранее, какие URI использовать для следующих действий; он должен следовать ссылкам, как в веб-браузере. На практике это ограничение часто не соблюдается в современных RESTful API.

¶5. Слоистая система (Layered System)

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

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

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

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

В RESTful-системах ресурсы — это ключевые сущности, с которыми работает приложение. Каждый ресурс имеет уникальный URI. Взаимодействие с ресурсами происходит через стандартные методы HTTP, которые действуют как глаголы.

¶Основные HTTP-методы

¶Пример RESTful API

Предположим, есть API для управления пользователями.

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

¶Представления данных

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

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

¶Применение

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

• Веб-API (Web APIs): Большинство публичных API крупных компаний (Google, Twitter, GitHub, Amazon, VK) реализованы в стиле REST. Они позволяют сторонним разработчикам интегрировать свои приложения с этими сервисами.
• Микросервисная архитектура (Microservices): В микросервисной архитектуре каждое приложение разбивается на множество небольших, независимых сервисов. RESTful API является одним из основных способов взаимодействия между этими сервисами.
• Мобильные приложения: Мобильные приложения (iOS, Android) часто общаются с серверной частью через RESTful API, получая данные в формате JSON.
• Интернет вещей (IoT): Устройства IoT (датчики, умные лампы, термостаты) могут отправлять и получать данные через RESTful API.
• Веб-приложения (SPA — Single Page Applications): Современные одностраничные приложения (React, Angular, Vue.js) используют RESTful API для динамической загрузки данных и обновления интерфейса без перезагрузки страницы.

¶Критика и ограничения

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

• Отсутствие строгой спецификации: REST — это архитектурный стиль, а не протокол. Это приводит к разночтениям в реализации. Многие API, называющие себя RESTful, на самом деле не соблюдают все ограничения, особенно HATEOAS.
• Избыточность при большом количестве запросов: Для получения сложных данных (например, профиля пользователя и его последних заказов) может потребоваться несколько запросов (N+1 проблема), что увеличивает сетевую нагрузку. Для решения этой проблемы используются такие техники, как GraphQL или расширения REST (например, JSON:API, OData).
• Сложность с версионированием: Изменение API может привести к поломке клиентов. Для решения этой проблемы используются различные стратегии версионирования (через URI, заголовки или параметры запроса).
• Проблемы с безопасностью: RESTful API уязвимы для атак, таких как CSRF (межсайтовая подделка запроса), XSS (межсайтовый скриптинг) и инъекции. Требуется тщательная реализация механизмов аутентификации и авторизации (например, OAuth 2.0, JWT).
• Сложность с HATEOAS: Реализация HATEOAS на практике сложна и часто неоправданна, что привело к тому, что большинство API его игнорируют.

¶Источники

• Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures (Doctoral dissertation, University of California, Irvine).
• Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly Media.
• Fielding, R. T., & Taylor, R. N. (2002). Principled design of the modern Web architecture. ACM Transactions on Internet Technology (TOIT), 2(2), 115-150.
• Спецификация HTTP/1.1 (RFC 7230-7235).