Введение

REST – термин такого же рода как “объектно-ориентированный”. Под этим терминов понимается подход к архитектуре. Это если в общих словах.

Точно также как и в ООП есть некоторых набор концепций (инкапсуляция, наследование, полиморфизм), так и REST определяет некоторый набор принципов (statelessness, addressability, connectedness, единый интерфейс и т.д.).

В ООП также есть свои понятия:

• класс
• объект
• методы
• передача сообщений

В REST тоже есть свои понятия:

• Resource – ресурс (например, список ссылок)
• Representation – виды ресурса (например, html – страница со ссылками в браузере, rss – таже страница, но в для рсс-фида)
• Адрес ресурса (например, URL страницы)
• Единый интерфейс (GET, POST, PUT, DELETE и другие методы для HTTP-протокола)

Точно также как можно написать программу на объектно-ориентированном языке не используя никаких из принципов ООП, так и сайты, что хоть и доступны с помощью отличной реализации REST-принципов – протокола HTTP, сами эти REST принципы могут и не использовать.

Понятия REST (поподробнее)

Ресурс

Ресурс – под ресурсом понимается все что угодно достаточно важное для того, чтобы иметь ссылку на себя. Ресурсом может быть ссылка, карта города, статья в энциклопедии об осьминоге, случайное число больше 100 и меньше 323.

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

Адрес

Адрес – это имя ресурса, его местоположение. Ресурс может иметь несколько адресов, от одного и больше.

В вебе, у нас есть своей название для адреса – URL, universal resource locator.

Представление ресурса (representation)

Стоит различать ресурс и его представление. Ресурс – это некоторая идея то, что находится.
Когда пользователь заходит на страницу /shop, он получает не идею ресурса, а определенный набор байтов, данные – это и есть представление ресурса. Сервер может по запросу /shop вернуть набор товаров в этом магазине, а может вернуть изображение этого магазина на карте.

Представление ресурса – это информация о текущем состоянии ресурса.

Информация о том какое представление следует выбрать, если их доступно несколько, может находится как и в адресе ресурса (например, если это страница в журнале, /article.en указывает на английскую версию, /article.ru – на русскую), так и зависеть от контекста запроса (в этом примере, клиент посылает http-заголовок о том, где он находится и какой язык предпочитает)

Принципы REST (поподробнее)

Addressability

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

Возьмем к пример, Gmail. Так весь интерфейс построен на ajax’e, нет очевидной возможности обратится к некоторому письму напрямую по адресу. Поэтому для доступа к отдельному письму приходится заходить на Gmail и вручную выбирать его из списка. Если тебе позже понадобится это письмо, то придется проделывать все эти действия еще раз. Добавить ссылку на письмо в текстовый файл, в букмарки не выйдет, т.к. адреса нет.

Statelessness

Отсутствие состояния. Это означает, что любой запрос к ресурсу происходит в полной изоляции, т.к. как будто этот запрос был выполнен впервые. Запрос не зависит ни от каких данных из прошлых запросов. Все необходимая информация находится в теле запроса.

Connectedness

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

Приведу пример. Представим, что было бы если Google Maps не возвращал кнопок “вверх-вниз”, “влево-вправо”, “увеличить-уменьшить”. Единственный способ навигации для пользователя – это запоминать текущую широту и долготу и вручную править градусы левее или правее, чтобы увидеть следующий участок на карте. Вряд ли бы таким сервисом кто-то пользовался.

Но если рассматривать не пользовательский веб, а веб-сервисы, которые созданы для компьютера, а не человека, то такая проблема будет довольно распространена.

Единый интерфейс

Единый интерфейс означает лишь то, что каждый ресурс использует одни и те же методы для доступа к своим данным. Причем важно не то, как эти методы называются, а то что они выполняют схожую функции независимо от ресурса.

В вебе, метод GET – означает получить представление об ресурсе. Было бы странно увидеть сайт, на которым с помощью GET’a удалялись статьи, а с помощью POST можно было увидеть ее представление. Со стандартным браузером таким сайтом было бы невозможно пользоваться, т.к. браузер рассчитывает получить представление с помощью метода GET, а с помощью POST – отправить команду на обновление или удаление.

Это все.

Все, что нужно знать про REST. Четыре понятия и четыре принципа. Конечно, еще много вопросов остается открытыми, но об этом поговорим потом.

P.S. На самом деле я хотел набросать себе небольшую подсказку, как распределить реальные данные по ресурсам, какие шаги нужно выполнить и так далее, и так далее, но об этом позже.