REST и RESTful — передача репрезентативного состояния и ресурсный роутинг

REST — это стиль построения архитектуры распределенного клиент‑серверного приложения, который упрощает роутинг и построение API.

REST сейчас уже стандарт проектирования архитектуры веб‑приложений:

• Очень многие веб‑фреймворки работают с RESTful роутингом (например, Ruby on Rails и Yii).
• Практически все популярные сервисы имеют RESTful API.

REST является очень простым интерфейсом управления информацией без использования дополнительных внутренних прослоек, то есть передача данных осуществляется без избыточных «обёрток». Каждый объект однозначно определяется глобальным идентификатором, таким как URL, а каждый URL имеет строго заданный формат. Управление этими ресурсами осуществляется с помощью стандартного интерфейса, например, через HTTP(S), а обмен информацией происходит с помощью представлений этих ресурсов.

Пример ресурсного роутинга:

• GET /articles/ — возвращает все статьи
• GET /articles/new — форма для создания новой статьи
• POST /articles/ — создаёт новую статью
• GET /articles/1 — возвращает статью с идентификатором «1»
• GET /articles/1/edit — форма редактирования статьи
• PATCH или PUT /articles/1 — обновляет статью с идентификатором «1»
• DELETE /articles/1 — удаляет статью с идентификатором «1»

Критика REST

Однако, несмотря на распространённость, REST часто критикуют. Происходит это из‑за того, что жёстко формализованного стандарта реализации RESTful API не существует.

Часто проблемы возникают на уровне соответствий HTTP‑кодов ответа сервера и тела ответа. Не для каждого кейса можно подобрать адекватный код ответа, да и обработка клиентом усложняется при передаче информации не только в теле ответа, но и в статус‑коде. Использование кодов, отличных от 200, 404 и 500, обычно усложняет работу с API, особенно из браузеров, так как реализация реакции на одни и те же коды может отличаться (и отличается) в разных браузерах.

REST также сильно привязан к трансферному протоколу HTTP(S) — это усложняет его использование, например, через веб‑сокеты.

Критикуют и работу с методами. Методы PATCH и DELETE часто реализуются через POST с передачей флага, обозначающего реальный тип запроса. Это добавляет еще один параметр в и без того насыщенный список.

По сути, в REST мы должны анализировать метод запроса (включая описанный выше параметр переназначения для patch & delete), путь запроса до ресурса, тело запроса, код ответа HTTP, код ответа в теле ответа, тело ответа.

Всё это усложняет отладку и сопровождаемость.

А обходят это обычно через повсеместное использование кода ответа 200 ОК, через строгое использование глаголов действий непосредственно в теле запроса, а кодов ответа — в теле ответа. Это «отвязывает» использование API от особенностей транспортного протокола, но при этои превращает REST уже во что‑то иное.