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 уже во что‑то иное.
Тематические статьи
Стандарты кодирования — залог хорошей сопровождаемости проекта
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение.
Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
SOLID — принципы объектно‑ориентированного программирования
SOLID это аббревиатура пяти основных принципов проектирования в объектно‑ориентированном программировании, предложенных Робертом Мартином:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
Принцип программирования YAGNI — «Вам это не понадобится»
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться.
В результате разработка ненужных функций не сжигает бюджет проекта, а разработчики не тратят оплачиваемое время на реализацию и дальнейшее сопровождение в реальности ненужного функционала. Избыточный функционал сжигает больше всего ресурсов именно на сопровождении: больше написанного кода — труднее сопровождать и выше вероятность появления «багов». И тут очень уместна поговорка: «лучший код — это ненаписанный код».
Принцип программирования KISS — делайте вещи проще
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.
Большая часть программных систем необосновано перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу DRY позволяет добиться высокой сопровождаемости программного продукта: внесение изменений и тестирование значительно упрощаются.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте. Также значительно проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. При следовании DRY упрощается и повторное использование функций, вынесенных из сложных алгоритмов, что позволяет сократить время разработки и тестирования новой функциональности.
TDD — разработка через тестирование
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов.
TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.