В главе 1 мы сориентировались, сформировав модель двух сторон, задействованных в API — сервера и клиента. Имея твердое представление об этих сторонах, мы готовы глубже изучить, как эти двое общаются. Для контекста мы сначала посмотрим на человеческую модель общения и сравним её с компьютерной. После этого мы перейдем к деталям общего протокола, используемого в API.

Люди создают правила этикета, чтобы регламентировать взаимодействия между собой. Один из примеров — то, как мы разговариваем друг с другом по телефону. Представьте, что вы болтаете с подругой. Пока она говорит, вы знаете, что нужно молчать. Если она задаёт вопрос, а затем молчит, вы знаете, что она ждёт ответа и теперь ваша очередь говорить.

Компьютеры придерживаются аналогичного этикета, хотя и называется он термином «протокол». Компьютерный протокол — это принятый набор правил, которые определяют, как два компьютера могут общаться друг с другом. Однако по сравнению с нашими стандартами компьютерный протокол чрезвычайно строгий. Подумайте на минуту о двух предложениях: «Мой любимый цвет — синий» и «Синий — мой любимый цвет». Люди могут определить каждое предложение и понять, что они означают одно и то же, несмотря на то, что слова расположены в разном порядке. К сожалению, компьютеры не настолько умны.

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

В мире технологий практически для всего существует протокол, и каждый из них заточен для выполнения своих задач. Возможно, вы уже слышали о некоторых из них: Bluetooth для подключения устройств и POP или IMAP для получения электронной почты.

В интернете основным протоколом является протокол передачи гипертекста, более известный под аббревиатурой HTTP (HyperText Transfer Protocol, протокол передачи гипертекста). Когда вы вводите адрес вроде http://example.com в веб-браузере, «http» указывает браузеру использовать правила HTTP-протокола при разговоре с сервером.

С повсеместным распространением HTTP в интернете многие компании предпочитают адаптировать его для использования в качестве протокола, лежащего в основе своих API-интерфейсов. Одним из преимуществ использования этого протокола является то, что он прост в изучении разработчиками. Еще одним преимуществом является то, что HTTP имеет несколько свойств, полезных для создания хорошего API, которые мы увидим позже. А сейчас давайте нырнём глубже и посмотрим, как работает HTTP!

Взаимодействие в HTTP основано на концепции, называемой Циклом «Запрос-Ответ». Клиент отправляет серверу запрос на выполнение каких-либо действий. Сервер, в свою очередь, отправляет клиенту ответ, в котором говорит, может ли он сделать то, что просил клиент.

Чтобы сделать правильный запрос, клиент должен указать четыре вещи:

1. URL (Uniform Resource Locator, единый указатель ресурсов)
2. Метод (Method)
3. Список Заголовков (Headers)
4. Тело (Body)

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

URL-адреса знакомы нам в повседневном использовании интернета, но задумывались ли вы когда-нибудь об их структуре? В HTTP URL — это уникальный адрес какого-либо объекта. Каким объектам давать адреса — полностью решает организация, которая управляет сервером. Компании могут создавать URL-адреса для веб-страниц, изображений или даже видео с котиками.

API развивают эту идею, добавляя в контекст URL такие объекты, как, например, клиенты, продукты и твиты. В результате URL-адреса становятся для клиента простым способом сообщить серверу, с каким объектом он хочет взаимодействовать. Конечно, API не называют их «объектами», им дают техническое название «ресурсы».

Метод запроса сообщает серверу, какое действие клиент хочет, чтобы сервер предпринял. Фактически, метод обычно называют «глаголом» запроса.

В API-интерфейсах чаще всего встречаются четыре метода:

• GET — просит сервер получить ресурс
• POST — просит сервер создать новый ресурс
• PUT — просит сервер отредактировать/обновить существующий ресурс
• DELETE — просит сервер удалить ресурс

Вот пример, который поможет проиллюстрировать эти методы. Допустим, есть пиццерия с API, который можно использовать для размещения заказов. Вы размещаете заказ, отправляя POST-запрос на сервер ресторана с перечнем вашего заказа с просьбой создать вашу пиццу по этим ингридиентам. Однако после того как вы отправили запрос, вы понимаете, что выбрали неправильные ингредиенты, поэтому вы делаете запрос PUT, чтобы изменить его.

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

Заголовки предоставляют метаинформацию о запросе. Это простой список элементов, таких как время отправки запроса клиентом и размер тела запроса.

Помните, как вы заходили со своего смартфона на веб-сайт, специально отформатированный для мобильных устройств? Это стало возможным благодаря HTTP-заголовку под названием «User-Agent». Клиент использует этот заголовок, чтобы сообщить серверу, какой тип устройства вы используете, и если веб-сайт достаточно умён чтобы прочесть его, то в результате отправит вам данные в наиболее удобном для вашего типа устройства формате.

В целом существуют довольно много разных заголовков HTTP, с которыми имеют дело клиенты и серверы, но давайте рассмотрим их позже, в следующих главах.

В теле запроса содержатся данные, которые клиент хочет отправить серверу. Продолжая наш пример с заказом пиццы выше, тело — это место, где размещаются ингредиенты заказа.

Уникальной чертой тела является то, что клиент полностью контролирует эту часть запроса. В отличие от метода, URL-адреса или заголовков, где протокол HTTP требует жёсткой структуры, тело позволяет клиенту отправлять всё, что ему нужно.

Эти четыре части — URL, метод, заголовки и тело — составляют полный HTTP-запрос.

После того, как сервер получает запрос от клиента, он пытается выполнить запрос и отправить клиенту ответ. HTTP-ответы имеют очень похожую на запросы структуру. Основное отличие состоит в том, что вместо метода и URL-адреса ответ включает код состояния. А в остальном заголовки и тело ответа имеют тот же формат, что и запросы.

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

Код состояния, связанный с этим ответом — 404, что означает «Не найдено». Всякий раз, когда клиент делает запрос на ресурс, который не существует, сервер отвечает кодом состояния 404, чтобы сообщить клиенту: «этот ресурс не существует, поэтому, пожалуйста, не запрашивайте его снова!»

В протоколе HTTP есть множество других статусов, от 200 («успешно! этот запрос был выполнен») до 503 («наш веб-сайт/API в настоящее время не работает»). Мы изучим некоторые из них по мере их появления в следующих главах.

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

Теперь вы понимаете, что HTTP поддерживает большое количество функциональных сочетаний, чтобы помочь клиенту и серверу общаться. Итак, как это помогает нам с API? Гибкость HTTP означает, что построенные на нём API могут предоставить клиентам большой бизнес-потенциал. Мы видели этот потенциал в приведённом выше примере заказа пиццы. Простое изменение метода запроса дало понять серверу, что нужно сделать: создать новый заказ или отменить существующий. Было легко превратить желаемый бизнес-результат в инструкцию, понятную серверу. Очень мощно, не так ли!

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

Целью этой главы было дать вам базовое понимание HTTP. Ключевой концепцией был Цикл Запрос-Ответ, который мы разделили на следующие части:

• Запрос — состоит из URL-адреса (http://...), метода (GET, POST, PUT, DELETE), списка заголовков (User-Agent...) и тела (данных).
• Ответ — состоит из кода состояния (200, 404...), списка заголовков и тела.

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

В следующей главе мы исследуем, какого типа данные API передают между клиентом и сервером. Идём к 3-й главе!