Перейти к содержанию

REST

REST (Representational State Transfer) — архитектурный стиль взаимодействия компонентов распределённого приложения в сети. REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы.
Принципы REST лежат в основе веба 1.0 и протокола HTTP, термин был введён Роем Филдингом, одним из создателей протокола HTTP в 2000 году.

По принципам REST построена работа самого HTTP и всего web 1.0 - страничек в интернете с ссылками на другие страницы. Но, каким-то магическим образом, REST’ом начали называть любой обмен JSON’ами по HTTP. Как это произошло - загадка.

Существует шесть обязательных ограничений для построения распределённых REST-приложений по Филдингу. Выполнение этих ограничений обязательно для REST-систем:

  1. Модель клиент-сервер.
    Клиент и сервер должны быть отделены друг от друга и иметь возможность развиваться индивидуально.
  2. Отсутствие состояния.
    Вызовы API могут выполняться независимо друг от друга, и каждый вызов содержит все данные, необходимые для успешного завершения.
  3. Кэширование.
    REST API должен быть разработан таким образом, чтобы поощрять кэширование данных.
  4. Единообразие интерфейса.
    Ключом к отделению клиента от сервера является наличие единого интерфейса, который обеспечивает независимую эволюцию приложения без тесной связи служб или моделей и действий приложения с самим уровнем API.
  5. Слои.
    API-интерфейсы REST имеют разные уровни архитектуры, работающие вместе для построения иерархии, которая помогает создать более масштабируемое и модульное приложение.
  6. Код по требованию (необязательное ограничение).
    Код по запросу позволяет передавать код или апплеты через API для использования в приложении.

Система, которая не удовлетворяет 5 обязательным требованиям не может называться RESTful.
Реализуя все ограничения REST взамен получаем свойства этой архитектуры: гибкость, низкая связанность между клиентом и сервером, масштабируемость, удобство реализации системы безопасности API и его развития со временем.

Большинство ограничений легко соблюсти просто используя HTTP. Наименьшее внимание уделяют пункту “единообразие интерфейса” - центральному требованию архитектуры REST, которое отделяет его от остальных стилей.
Согласно этому пункту, помимо всего прочего, API должен быть построен с использованием чего-то вроде HATEOAS (Hypermedia as the Engine of Application State).
На практике это выглядит следующим образом. Например, мы запрашиваем информацию о книге вызывая GET http://book-store.org/books/0321127420, в ответ получаем не только информацию по самой сущности, но и ссылки на действия, которые мы можем сделать с этой сущностью:

{
   "isbn": "0321127420",
   "title": "Patterns of Enterprise Application Architecture",
   "available": 1,
   "_links": {
       "self": {
           "href": "http://book-store.org/books/0321127420"
       },
       "purchase": {
           "href": "http://book-store.org/books/0321127420/purchase"
       },
       "publisher": {
           "href": "http://book-store.org/publishers/2"
       }
   }
}

При использовании HATEOAS клиент должен знать только базовый адрес сервиса (GET http://book-store.org/). Остальные URI он получает через навигацию по ссылкам в ответах на запросы. Эта схема как раз и позволяет добиваться низкой связанности между клиентом и сервисом - что является главной целью REST.

Quote

Что нужно сделать, чтобы все четко понимали, что гипертекст является обязательным ограничением REST? Другими словами, если механизм состояния приложения (и, следовательно, API) не управляется гипертекстом, то он не может быть RESTful и не может быть REST API. Точка. Есть ли где-то сломанное руководство, которое нужно исправить?
-- Roy T. Fielding

На мой взгляд, все споры PUT vs PATCH, какой HTTP код возврата использовать при обращении к отмененному заказу 404 или 410 имеют еще меньше практического смысла, чем споры вида табы против пробелов. Все это больше эстетические вопросы. Ответы на них не повлияют ни на что в вашей системы, не добавят ей никаких новых качеств. С точки зрения REST архитектуры это незначительные детали реализации, которые даже не затрагиваются Роем в своей диссертации.

Какие выводы стоит из этого сделать:

  1. REST не имеет никакого отношения к передачи JSON по HTTP.
  2. REST не существует без HATEOAS.
  3. Большинство взаимодействий между сервисами больше похожи на удаленные вызовы процедур (RPC).

Модель зрелости API Ричардсона:

Уровень 0: Болото POX

API с одним URI (обычно POST через HTTP), принимающим весь диапазон операций, поддерживаемых службой.

Уровень 1: Ресурсы

Представляет ресурсы и позволяет делать запросы к отдельным URI (все еще обычно POST) для отдельных действий вместо предоставления одной универсальной конечной точки (API).

Уровень 2: HTTP-глаголы

Запросы GET только извлекают данные, вызовы POST / PUT вводят новые и обновляют существующие данные, запросы DELETE удаляют или иным образом делают недействительными предыдущие действия.

Уровень 3: Элементы управления Hypermedia

Также называемые HATEOAS (гипермедиа как механизм состояния приложения), это элементы, встроенные в ответные сообщения ресурсов, которые позволяют установить связь между отдельными объектами данных, возвращаемыми из API, и передаваемыми им.

Ссылки: