API First. Архитектура REST

API сервисы раньше и сейчас

Пока не было мессенджеров и смартфонов — в интернет выходили с настольного компьютера, а единственным пользовательским клиентом был веб-браузер. Сайты работали так: сервер получал запрос и отдавал клиенту готовые HTML-страницы.
В современном мире у такого подхода есть два недостатка:
  • HTML-страница нужна браузеру, но не мобильному приложению — данные внутри него организованы иначе. Но если у какого-то сервиса есть и сайт, и мобильное приложение, они будут общаться с одним сервером. Поэтому разработчику придётся делать для мобильного приложения отдельный способ получения данных.
  • Поскольку HTML-код генерируется на сервере, при переходе от страницы к странице браузер перезагрузит сайт целиком. Это неэффективно, поскольку приходится перерисовывать одинаковые элементы: шапку, меню, подвал. Разумнее получить данные об изменяющихся частях сайта и отрисовать только их.
Размышляя об этих проблемах, Тим Бёрнерс-Ли (которого можно назвать создателем интернета) и Рой Филдинг (его коллега) придумали принципы, которые позволяли бы масштабировать развитие всемирной сети.
Основная идея в том, что с сервера возвращают только данные, а клиент уже сам разбирается, как эти данные отрисовать. Мобильное приложение будет использовать свои методы отрисовки, браузер или чат-бот — свои. Так мы ограничиваемся одним API для разных платформ. Такой подход получил название API-First, то есть сначала данные, а затем — интерфейсы для их отображения.
Так появился REST.

REST

REST, или REpresentational State Transfer (англ. «передача состояния представления») — это набор принципов, которых следует придерживаться при создании API. Если API сделан по этим принципам, его называют RESTful API (или просто REST API).
Эти принципы стандартизируют передачу данных по сети, они похожи на правила вежливости, когда людям (серверам) удобно находиться в одном обществе (интернете) и понимать друг друга.

Принципы REST

Эти принципы ввёл Рой Филдинг (Roy Fielding) в 2000 году, в своей диссертации «Архитектурные стили и дизайн сетевых программных структур».

1. Клиент-сервер. Разделение ответственности между клиентом и сервером

Клиент и сервер отвечают за разные вещи. Ответственность клиента — пользовательский интерфейс, ответственность сервера — данные. Если API возвращает HTML-страницу, его нельзя назвать REST API: ведь при этом сервер берёт на себя ответственность за интерфейс.

2. Отсутствие состояния. Сервер не хранит состояние

Каждый запрос должен быть независимым, как будто он сделан в первый раз. Сервер не должен хранить какой-либо информации о клиенте. Запрос клиента к серверу должен содержать всю информацию, необходимую для обработки этого запроса: кто запрашивает данные, какие данные запрашиваются.

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

Интерфейс обращения к серверу одинаков для всех и не зависит от клиента. Запрос к данным может быть сформирован из браузера, мобильного приложения и с умного чайника по одним и тем же правилам.

4. Многоуровневость

Первый принцип гласит, что в коммуникации участвуют двое: клиент и сервер. Но можно строить более сложные системы, не нарушая этого принципа.
API сервиса Яндекс.Такси может использовать API Яндекс.Навигатора. Вы как клиент взаимодействуете только с API Яндекс.Такси, а он в свою очередь является клиентом навигатора. Здесь есть одно условие — каждый компонент должен видеть только свой уровень, например, Яндекс.Навигатор не должен видеть все данные, которые вы отправили в Яндекс.Такси.

5. Кэшируемость

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

6. Код по запросу

Этот принцип необязательный. Он гласит, что функциональность клиента может быть расширена кодом, приходящим с сервера. Сейчас такое можно встретить повсеместно: JavaScript используется для «оживления» страниц и исполнения каких-то сценариев на стороне клиента. Но принципы формулировались в 2000 году — тогда исполняемый код с сервера возвращали не так часто. Потому и выделили это в отдельный принцип.
Что такое REST?