Теория REST API

Первый модуль закончился тем, что вы создали HTTP-запрос, отправили его и получили ответ.

В дальнейшем мы еще много раз будет делать это. Будем отправлять запросы на сторонние серверы. Будем делать приложения, которые сами принимают такие запросы и возвращают ответ. Будем создавать сложную логику обработки запросов.

Поэтому хорошо бы основательно изучить все, что касается этих запросов, разобрать их детально. Чтобы можно было не просто скопировать где-то запрос и повторить его, а действительно разобраться, как это все устроено.

Именно этим мы и займемся во втором модуле. Поехали!

Общая теория

Для начала теория.

Если вы выполняли домашнее задание в первом модуле и изучали документацию, то должны были обратить внимание на аббревиатуру API. Собственно именно документация API - это первое, что должен изучить разработчик, если хочет разобраться во взаимодействии с каким-то сервисом или приложением в сети.

API

API - Application Programming Interface. Или по-русски - программный интерфейс приложения. Это описание способов, которыми клиент и сервер могут взаимодействовать друг с другом. Мы открываем документацию API и узнаем оттуда, как же получить нужные данные с сервера.

Всегда хочется, чтобы это взаимодействие было простым и понятным. Это упрощает задачу как разработчиков (не нужно заново изобретать велосипед при проектировании нового сервиса), так и пользователей (сервис гораздо проще освоить, если он работает по тому же принципу, как и уже знакомые ранее сервисы). И вот тут стоит запомнить новый термин - REST.

REST

REST - акроним от английского Representational State Transfer. По-русски - передача состояния представления. Может звучать не очень понятно, но если проще, то REST - стиль взаимодействия (обмена информацией) между клиентом и сервером.

Это не какой-то жесткий свод правил и требований. REST не заставляет использовать какой-то определенный язык программирования, не связывает руки строгими указаниями. REST называют архитектурным стилем и он определяет 6 принципов, которым должна соответствовать архитектура системы.

Соответственно, API разработанное с учетом принципов REST называется REST API, а сами приложения - RESTful

Мы будем создавать именно RESTful-приложения поэтому стоит сразу обговорить принципы, которым они будут соответствовать.

Принципы REST API

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

Отсутствие состояния. Этот принцип означает, что сервер не должен “додумывать” ответ основываясь на предыдущем опыте взаимодействия с данным клиентом. Любой запрос составляется так, что содержит всю необходимую информацию для его обработки, независимо от предыдущих запросов.

Кэширование. Для минимизации передаваемых данных существует механизм кэширования. Например, если на какой-то странице отображается логотип, то нет смысла каждый раз запрашивать его с сервера. Он не так часто меняется, достаточно будет получить один раз и сохранить на компьютере клиента, в кэше. А вот если нам требуется получить информацию о текущей скорости автомобиля, то кэш уже никак не поможет.  Данный принцип и определяет то, что данные передаваемые сервером, должны обозначаться как кэшируемые или нет.

Единообразие интерфейса. Принцип определяет единый формат клиент-серверного взаимодействия. Структура всех запросов должна быть одинаковой. Данные должны отправлять в едином виде, независимо от того, кто их запрашивает.

Многоуровневая система. Клиент и сервер не обязательно взаимодействуют напрямую. Передача данных может идти через несколько промежуточных узлов. При этом система проектируется так, что ни клиент, ни сервер, не знают, взаимодействуют ли они с конечным приложением, или промежуточным узлом. Это позволяет сбалансировать нагрузку на сервера, повысить масштабируемость.

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