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 уже во что-то иное.

REST — архитектурный стиль построения веб-сервисов, чаще всего используемый для API. По сути, это набор соглашений, позволяющих стандартизировать работу с системой, предоставив единообразный интерфейс.

HTTPS — расширение протокола HTTP, поддерживающее шифрование. Передаваемые по протоколу HTTPS данные зашифрованы, что обеспечивает защиту от прослушивания. HTTPS широко используется в мире и поддерживается всеми популярными браузерами.

Узнать больше →

HTTPS защищает передаваемые данные от перехвата и модификации при помощи шифрования.

Cтатьи по теме:

Парадигма MVC — модель-представление-контроллер
MVC или модель-представление-контроллер — это паттерн проектирования веб-приложений, который включает в себя несколько более мелких шаблонов. При использовании MVC модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента, благодаря чему модификация одного из них оказывает минимальное воздействие на остальные или не оказывает его вовсе.
Стандарты кодирования — залог хорошей сопровождаемости проекта
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Иначе разработка начинает напоминать басню Крылова «Лебедь, Щука и Рак».
SOLID — принципы объектно-ориентированного программирования
SOLID это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании — Single responsibility, Open-closed, Liskov substitution, Interface segregation и Dependency inversion. В переводе на русский: принцип единственной ответственности, принцип открытости / закрытости, принцип подстановки Барбары Лисков, принцип разделения интерфейса и принцип инверсии зависимостей.
Принцип программирования YAGNI — «Вам это не понадобится»
Если упрощенно, то следование данному принципу заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. Это позволяет вести разработку, руководствуясь экономическими критериями — Заказчик не должен оплачивать ненужные ему функции, а разработчики не должны тратить своё оплачиваемое время на реализацию того, что не требуется.
Принцип программирования KISS — делайте вещи проще
Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу «KISS» позволяет разрабатывать решения, которые просты в использовании и в сопровождении.
Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу программирования «DRY» позволяет добиться высокой сопровождаемости проекта: простоты внесения изменений и качественного тестирования.
Принципы SOLID: принцип единственной ответственности
Принцип единственной ответственности — один из пяти основных принципов объектно-ориентированного программирования и проектирования, сформулированных Робертом Мартином. Принцип декларирует, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс, а все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.

Тематические технологии:

Язык программирования Ruby
Фреймворк Ruby on Rails
Язык программирования Python
Язык программирования Go
Язык программирования Elixir
Фреймворк Phoenix
Websockets
Язык разметки HTML