Диссертация Филдинга о REST

REST — это гибридный архитектурный стиль, полученный из нескольких сетевых архитектурных стилей, описанных в Главе 3 у Филдинга. Объединен с дополнительными ограничениями, которые определяют единый интерфейс (п.4. ниже).

Цитата: "REST состоит из набора ограничений, которые навязываются потенциальным архитектурам."

Рекомендуемые "ограничения" (правила):

  1. Client-Server. Используем взаимодействие "Клиент-сервер".
  2. Stateless. Не храним состояние взаимодействия. Каждый запрос "как первый" т.е. клиент передает всю информацию для понимания запроса. Состояние сеанса, если угодно, полностью хранится на клиенте.
  3. Cache. Ограничения кэша требуют, чтобы данные в ответе были неявно или явно помечены как кэшируемые или некэшируемые. Если ответ кэшируемый, то кэш клиента получает право повторно использовать данные этого ответа для последующих эквивалентных запросов.
  4. Uniform Interface. Интерфейс взаимодействия един для всех (не подстраивается под специфику клиента). Характеризуется четырьмя ограничениями интерфейса: идентификация ресурсов (Resources and Resource Identifiers), манипулирование ресурсами посредством представлений (Representations), самоописательные сообщения (self-descriptive messages) и гипермедиа в основе состояния (hypermedia). Подробнее ниже в Data Elements.
  5. Layered System. Многоуровневый системный стиль делает так, что каждый компонент не может «видеть» за пределами слоя, с которым он взаимодействует.  Слои можно использовать чтобы инкапсулировать устаревшие службы, создавать посредники улучшения масштабируемости системы, обеспечивать балансировку нагрузки.
  6. Code-on-demand. Допустимо расширять функциональность клиента путем загрузки и выполнения кода в форме applets или скриптов, чтобы не усложнять сам клиент.


Элементы архитектуры REST 

  1. Resources and Resource Identifiers. Ключевая абстракция RESTa - это ресурс. Любая информация может быть ресурсом и должна быть доступна через уникальные идентификаторы (например, URL).
  2. Representations. Представление состоит из данных и метаданных, описывающих данные. Обычно это сам запрашиваемый файл, документ и т.д.
  3. Connectors. Основные типы коннекторов — клиент и сервер. Клиент инициирует связь, отправляя запрос, сервер прослушивает соединения и отвечает на запросы, чтобы предоставить доступ к своим службам. Интерфейс коннектора похож на процедурный вызов, но есть нюансы. Входные параметры состоят из данных управления запросом, идентификатора ресурса, указывающего цель запроса, и необязательного представления. Выходные параметры состоят из данных управления ответом, необязательных метаданных ресурса и необязательного представления. Вызов является синхронным, но параметры могут передаваться и как потоки данных. 
    Также есть коннектор кеша, resolver (а-ля DNS-сервер) и tunnel (HTTP-протокол, например). 
  4. Components. Тут ключевая идея — разделить системы на компоненты (браузер, сервер, шлюз, прокси и т.д.). В основном важно подумать про прокси (proxy) и шлюзы (gateway (a.k.a., reverse proxy)) для безопасности, производительности, инкапсуляции и т.д.


Architectural Views (связка всего выше описанного на уровне "архитектурных представлений")

1. Представление процесса (Process View)

Представление процесса описывает взаимодействия между компонентами, раскрывая путь данных через систему. Например: Client -> Proxy -> Cache -> Server.
Системам нужно знать о существовании друг друга только в течение области их коммуникации.

2. Представление коннекторов (Connector View) 

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

3. Представление данных (Data View)

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


Базовый источник: Architectural Styles and the Design of Network-based Software Architectures, Roy Thomas Fielding, 2000. UNIVERSITY OF CALIFORNIA, IRVINE.

Другие заметки

← К автору