API сервисы раньше и сейчас
Давным-давно, когда компьютеры были большие, а мониторы — маленькие, в интернет выходили с настольного компьютера, а единственным пользовательским клиентом был веб-браузер. Сайты работали по стандартной системе: сервер получал запрос и отдавал клиенту готовые HTML-страницы.В современном мире у такого подхода есть два недостатка:
- HTML-код нужен лишь браузеру. Например, мобильное приложение вполне обойдётся без HTML-форматирования, ему нужны лишь структурированные данные; мобильное приложение само позаботится об отображении полученных данных.
- Поскольку HTML-код генерируется на сервере, при переходе от страницы к странице браузер перезагружает сайт целиком. Это неэффективно: приходится перерисовывать одинаковые элементы: шапку, меню, подвал. Разумнее получить данные об изменяющихся частях сайта и отрисовать только их.
Размышляя об этих проблемах, Тим Бернерс-Ли (его называют создателем интернета) и Рой Филдинг (его коллега) придумали принципы, которые позволяли бы масштабировать развитие всемирной сети.
Основная идея в том, что сервер возвращает только запрошенные данные, а клиент сам разбирается, как эти данные отобразить. Мобильное приложение будет использовать свои методы отрисовки, браузер или чат-бот — свои. В результате можно ограничиться одним API для разных платформ.Такой подход получил название API First, то есть сначала данные, а затем — интерфейсы для их отображения.Так появился REST.
REST
REpresentational State Transfer,REST (англ. «передача состояния представления») — это набор принципов, которых следует придерживаться при создании API. Если API сделан по этим принципам, его называют RESTful API (или просто REST API).
Эти принципы стандартизируют передачу данных по сети; они похожи на правила вежливости, когда людям (серверам) удобно находиться в одном обществе (интернете) и понимать друг друга. И хотя за нарушение этих правил никого не накажут — всем становится лучше, если эти правила соблюдаются.
Принципы REST
Эти принципы ввёл Рой Филдинг в 2000 году в своей диссертации «Архитектурные стили и дизайн сетевых программных структур».
1. Клиент-сервер. Разделение ответственности между клиентом и сервером
Клиент и сервер отвечают за разные вещи. Ответственность клиента — пользовательский интерфейс, ответственность сервера — данные. Если API возвращает HTML-страницу, его нельзя назвать REST API: ведь при этом сервер берёт на себя ответственность за интерфейс.
2. Отсутствие состояния. Сервер не хранит состояние
Каждый запрос должен быть независимым, как будто он сделан в первый раз. Сервер не должен хранить какой-либо информации о клиенте. Каждый запрос клиента к серверу должен содержать всю информацию, необходимую для обработки этого запроса: кто запрашивает данные, какие данные запрашиваются.
3. Единый интерфейс
Интерфейс обращения к серверу одинаков для всех и не зависит от клиента. Запрос к данным может быть сформирован из браузера, мобильного приложения и с «умного» чайника по одним и тем же правилам.
4. Многоуровневость
Первый принцип гласит, что в коммуникации участвуют двое: клиент и сервер. Но можно строить более сложные системы, не нарушая этого принципа.
API сервиса Яндекс.Такси может использовать API Яндекс.Навигатора. Вы как клиент взаимодействуете только с API Яндекс.Такси, а он, в свою очередь, является клиентом навигатора. Здесь есть одно условие — каждый компонент должен видеть только свой уровень. Например, Яндекс.Навигатор не должен видеть все данные, которые вы отправили в Яндекс.Такси.
5. Кешируемость
Данные ответа могут быть закешированы. Это значит, что можно сохранить полученные данные на клиенте, а при идентичном запросе взять их из памяти клиента — кеша, а не ждать их с сервера. Нет смысла запрашивать данные повторно, если они никак не изменились.
6. Код по запросу
Этот принцип необязательный. Он гласит, что функциональность клиента может быть расширена кодом, приходящим с сервера. Сейчас такое можно встретить повсеместно: JavaScript используется для «оживления» страниц и исполнения каких-то сценариев на стороне клиента. Но принципы формулировались в 2000 году — тогда исполняемый код с сервера возвращали не так часто. Потому и выделили это в отдельный принцип.