Что такое REST?

Начнем с определения того, что такое REST, а что нет. Для некоторых REST означает сервер, который обменивается документами JSON с клиентом через HTTP. Это не совсем так. Спецификация REST не требует HTTP или JSON. (В спецификации вообще не упоминается JSON или XML.)

Немного истории REST

Рой Филдинг представил архитектурный паттерн REST в своей дисертации, написанной им в 2000 году. В документе определены средства для клиентов и серверов при помощи которых производится обмена данными между приложениями. Главной особенностью является то, что клиенту ничего не нужно знать о приложении (сервере).

Филдинг не требует особых требований. Вместо этого он определяет REST относительно ограничений и архитектурных элементов.

Архитектурные ограничения REST

  • Клиент-сервер - приложения REST имеют сервер, который управляет данными и состоянием приложения. Сервер взаимодействует с клиентом, который в свою очередь обрабатывает взаимодействия с конечным пользователем. Это означает, что вы можете обновлять и улучшать каждую сторону и их компоненты по отдельности.
  • Без сохранения состояния - серверы не поддерживают хранение состояний клиента. Клиенты управляют состоянием своего приложения сами, а их запросы к серверу содержат всю информацию, необходимую для обработки.
  • Cacheable - сервер должен помечать свои ответы как кэшируемые или нет. Таким образом, клиенты могут кэшировать их, когда это возможно, для повышения производительности.
  • Единый интерфейс - это ограничение является наиболее известным правилом REST. Филдинг говорит: «Основная особенность, которая отличает архитектурный стиль REST от других - это упор на единообразный интерфейс между компонентами». Т.е. REST предоставляет данные, как ресурсы с согласованным пространством имен.
  • Многослойная система - компоненты системы не могут «видеть» за пределами своего уровня. Таким образом, вы можете легко добавить балансировщики нагрузки и прокси для повышения безопасности или производительности.

Служба RESTful - это больше, чем веб-сервер, который обменивается данными по средством JSON или любыми другими форматами данных. Все выше перечисленные ограничения работают вмести.

Применение ограничений

Во-первых, клиент-сервер, многоуровневая система и ограничения без состояния объединяются, чтобы сформировать приложение с твердыми границами и четким разделением задач. Данные передаются от сервера к клиенту по запросу. Клиент отображает или обрабатывает их. Если состояние изменяется, клиент отправляет его обратно на сервер для хранения. В REST клиент и сервер обмениваются знаниями о данных и состоянии. Архитектура не скрывает данные, она скрывает только реализации.

Ограничения кэшируемого и унифицированного состояния идут еще дальше. Данные приложения доступны клиентам в понятном и последовательном интерфейсе и по возможности кэшированы.

Это техническое определение REST. Как это выглядит в реальном мире?

RPC через HTTP против RESTful

Remote Procedure Call — вызов удалённых процедур. Их часто путают, смотря на URI или на то, как служба использует HTTP-команды. По тому, что складывается впечетлаение, что представление данных в REST это единый набор ресурсов.

Это различие иногда называют различием между вызовами удаленных процедур (RPC) и REST. Для примера разберем метод API для добавления и удаления товаров итернет магазина.

В одной версии есть один URL, который мы запрашиваем с помощью HTTP GET или POST. Мы взаимодействуем со службой, отправляя POST, задавая содержание, которое отражает то, что мы хотим сделать.

Дабавляем новый товар с помощью POST и NewItem: 

POST /item HTTP/1.1
{
    "NewItem": {
          "name": "new item",
          "price": "1.1",
          "id": "10"
      }
}

Запрос данных о товаре с помощью POST и ItemRequest: 

POST /item HTTP/1.1
{
    "ItemRequest": {
          "id": "10"
      }
}

Также можно использовать GET. 

GET /item?id=10 HTTP/1.1

Удаление или редактирование товаров с помощью POST и ItemDelete или ItemUpdate. 

POST /item HTTP/1.1
{
    "ItemDelete": {
          "id": "10"
      }
}

Это не REST. Мы не меняем состояние ресурсов. Мы вызываем функцию с аргументами, которые находятся в JSON или URL.

У службы RESTful есть URI для каждого товара.

Итак, добавление нового товара будет выглядеть как в примере выше. 

POST /item HTTP/1.1
{
    "Item": {
          "name": "new item",
          "price": "1.1",
          "id": "10"
      }
}

Но на этом сходство заканчивается. Получение элемента всегда выполняется GET: 

GET /item/10 HTTP/1.1

Удаление - это DELETE: 

DELETE /item/10 HTTP/1.1

Изменение элемента - это PUT: 

PUT /item HTTP/1.1
{
    "Item": {
          "name": "new item",
          "price": "2.99",
          "id": "10"
      }
}

Разница важна. В REST - операции используют отдельные действия HTTP. GET, POST, PUT, DELETE и PATCH имеют определенное назначение. Большинство хорошо продуманных API-интерфейсов REST также возвращают определенные HTTP-коды в зависимости от результата запроса.

Важным моментом является то, что URI работают с данными, а не с удаленными методами.

Но есть еще одна причина, по которой ресурсная модель важна.

REST против RESTful и модель зрелости Ричардсона

Когда вы моделируете свои URI после ресурсов и используете HTTP-команды, вы делаете свой API предсказуемым. Как только разработчики узнают, как вы определили свои ресурсы, они смогут почти предсказать, как будет выглядеть API. Здесь снова упор делается на понимание данных, а не операций.

Но даже если вы не можете сделать API полностью предсказуемым, вы можете задокументировать любую службу REST. Таким образом, каждый элемент, возвращаемый в рассмотреном выше приложении, будет содержать ссылки для удаления, изменения или установки уровня ресурса.

Многие API не соответствуют этому требованию, но называют себя REST. Дело в том, что многие так или иначе нарушают правила. В итоге мы получаем, что многие службы, которые мы называем REST, технически таковыми не являются.

REST, RESTful или RESTlike: имеет ли это значение?

Чем больше требований вы выполните, тем более "full" будет ваше приложение. При выполнении всех требований вы получайте RESTful приложение, если соблюдайте часть из них это RESTlike.

Итак, имеет ли значение сравнение REST и RESTful? Возможно нет. Насколько хорошо ваша архитектура соответствует произвольному стандарту, не так важно, чем то насколько она соответствует вашим потребностям и может ли она расти.

Архитектурный шаблон REST имеет много преимуществ. Филдинг разработал его еще в 2000 году, с тех пор многое изменилось. Но большинство ограничений, которые он имел в виду, все еще с нами. В 2000 году еще не было Android, iPhone или подобных систем. Но Филдинг понял, какие онлайн-приложения нужны и как веб-клиенты будут развиваться из механизмов отображения HTML в законченные приложения. Инструменты, которые мы используем сегодня, адаптированы к REST, а не наоборот.