REST. Краткий обзор
REST (REpresentational State Transfer) – это архитектурный стиль, набор принципов проектирования, позволяющий добиться определённых свойств системы, таких как:
-
Производительность
-
Масштабируемость
-
Гибкость к изменениям
-
Отказоустойчивость
-
Простота поддержки
-
REST — это не протокол. Он не определяет правила о том, как мы должны передавать запросы, какая у них должна быть структура, что мы должны возвращать в ошибках. В качестве протокола REST использует HTTP.
-
REST API (RESTful API) – это API, которые соответствуют принципам REST.
-
В архитектурном стиле REST нет ограничений по формату сообщений. REST API могут поддерживать любой формат сообщений, например XML, JSON, CSV, HTML и др.
-
REST фокусируется на ресурсах, доступ к которым осуществляется через URL.
-
Ресурс — это то, что доступно клиенту. Например, если мы пишем приложение для управления задачами, ресурсами могут быть Пользователь или Задача.
-
Ресурс имеет свой адрес (URI), по которому его можно найти и запросить.
-
HTTP-глаголы — это действия, которые можно выполнить над ресурсом. Например:
- GET /schedule/speech/id413 — получить информацию об объекте с идентификатором 413
Принципы REST
1. Клиент-серверная архитектура
Разделение зон ответственности между клиентом (кто использует API) и сервером (кто предоставляет API).
Преимущества:
- Масштабируемость. Если растёт нагрузка на сервер, мы можем добавить ещё серверы.
- Простота поддержки и гибкость изменений. Если нам нужно внести изменения, мы можем сделать это на сервере, а клиент будет видеть изменения без каких-либо доработок на своей стороне.
Недостатки:
- Единая точка отказа в виде сервера.
- Увеличение нагрузки на сервер и сеть. Так как клиент будет совершать меньше каких-либо действий самостоятельно, вырастет количество запросов между клиентом и сервером.
2. Stateless
Сервер не должен хранить у себя информацию о сессии с клиентом. Всю необходимую информацию для обработки клиент должен передавать в запросе. Сервер не может знать что-либо о предыдущих запросах от этого клиента.
Преимущества:
- Масштабируемость. Когда запрос имеет всю нужную информацию для обработки, то можно сделать несколько одинаковых серверов-обработчиков: допустим, 10 вместо одного.
- Простота поддержки. Можно увидеть в логах, какое сообщение приходило от клиента и какой ответ он получил.
- Кэширование.
Недостатки:
- Усложнение логики клиента. Именно на стороне клиента нам нужно хранить всю информацию о состоянии, о допустимых действиях, о недопустимых действиях и подобных вещах.
- Увеличение нагрузки на сеть. Каждый раз мы передаём всю информацию, весь контекст. Таким образом, больше информации гоняем по сети.
3. Кэширование
В оригинале это говорит о том, что каждый ответ сервера должен иметь пометку, можно ли его кэшировать. Кэширование снижает нагрузку на серверы и ускоряет получение ответа для клиента. Однако это может быть достаточно сложно в реализации. Нужно учитывать, что если отдаём какие-то данные, которые сохранили раньше, то они могли устареть.
4. Единообразие интерфейса. HATEOAS
Все запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда поступает запрос. Hypermedia as the Engine of Application State (HATEOAS) — одно из ограничений REST, согласно которому сервер возвращает не только ресурс, но и его связи с другими ресурсами и действия, которые можно с ним совершить. Например, если мы запрашиваем информацию о книге с помощью GET /books/1, то сервер может вернуть действия, которые можно сделать с книгой, например, добавить в корзину.
5. Слоистая архитектура
Ни клиент, ни сервер не должны знать о том, как происходит цепочка вызовов дальше своих прямых соседей. Между клиентом и сервером могут находится балансировщики, прокси, кэши.
6. Код по требованию
Передача исполняемого кода от сервера клиенту. Это позволяет клиенту стать гибче.
Подборка материалов
- REST, что же ты такое? — статья и вебинар от Systems Education
- Что такое REST API? — IBM
- Бесплатный курс по документированию REST API
- Серия видео Всё о REST API