Глава 7: Взаимодействие с API в режиме реального времени. API-интерфейсы для самых маленьких

Структура мини-курса Мини-курс API-интерфейсы для самых маленьких.

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

Подписка Веб-перехватчиков (Subscription webhooks): Неофициальное название для решений, которые делают настройку веб-перехватчиков автоматической.

Структура главы 7

Что такое API реального времени?

Примеры API в режиме реального времени

Интеграция API в реальном времени

Интеграция, ориентированная на клиента

Интеграция, управляемая сервером

Polling (опрос)

Long polling (Длинный опрос)

Webhooks

Subscription webhooks (Подписка вебхуков)

Краткое изложение главы 7

Что такое API реального времени?

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

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

Примеры API в режиме реального времени

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

Вот лишь несколько распространенных примеров API в режиме реального времени.

Устройства Интернета вещей (IoT) (Internet of Things (IoT) devices): Этот Bluetooth-термостат в вашем доме? API в режиме реального времени позволяют отслеживать температуру и изменять ее одним нажатием пальца.

Push-уведомления (Push notifications): каждый раз, когда вы получаете на свой телефон уведомление из календаря Google о начале встречи, о которой забыли, вы используете API в режиме реального времени.

Живой чат (Live chat): ваши любимые приложения для чата используют API-интерфейсы реального времени для отправки сообщений от одного пользователя к другому в тот момент, когда они нажимают кнопку отправки.

Геолокация (Geolocation): чтобы отслеживать ваше местоположение во время движения, приложениям GPS нужны API-интерфейсы в режиме реального времени.

Прямые трансляции данных (Live data feeds): брокерам с Уолл-стрит, которых вы видите в фильмах, нужны API-интерфейсы в режиме реального времени, чтобы следить за ростом и падением цен на акции на вращающемся цифровом биржевом табло.

Приложения ИИ (AI applications): API-интерфейсы облегчают взаимодействие в режиме реального времени между приложениями и моделями ИИ, позволяя этим приложениям анализировать текст, написанный человеком, обрабатывать его и выдавать ответы на основе данных из существующих наборов данных.

Интеграция API в реальном времени

Давайте вспомним, почему API полезны. В Главе 1 мы говорили, что API облегчают обмен данными между двумя системами (веб-сайтами, настольными компьютерами, смартфонами). Прямой обмен позволяет нам связывать системы вместе для формирования интеграции. Людям нравятся интеграции, потому что они упрощают жизнь. С интеграцией вы можете что-то сделать в одной системе, а другая автоматически обновит у себя данные.

Для наших целей мы разделим интеграции на две большие категории.

Первую мы называем «управляемой клиентом» (client-driven), когда человек взаимодействует с клиентом и хочет, чтобы данные сервера обновились.

Вторую мы называем «управляемой сервером» (server-driven), когда человек что-то делает на сервере и хочет, чтобы клиент знал об изменении.

Внимание. Клиенто-управляемый (client-driven) и серверо-управляемый (server-driven) — наши термины, так что не удивляйтесь, если вы используете один из них перед разработчиком и получите в ответ лишь пустой взгляд. Упомяните поллинг (polling) или веб-хуки (webhooks), если хотите мгновенной репутации.

Подобный паттерн (известный как опрос или поллинг) — наиболее часто встречающийся способ организации двунаправленной связи в API, когда партнёру требуется не только отправлять какие‑то данные на сервер, но и получать оповещения от сервера об изменении какого‑то состояния.
Вебхук (webhook) (веб-перехватчики) – это способ отправки уведомлений пользователю сайта. Если данные на сайте меняются, сервер создает HTTP-вызов и отправляет информацию получателю через вебхук. В данных будет указан тип события и ссылка на объект.

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

Интеграция, ориентированная на клиента

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

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

Интеграция, управляемая сервером

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

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

Polling (опрос)

Когда запросы может отправлять только клиент, простейшим решением для поддержания его в актуальном состоянии на сервере является простой запрос обновлений. Это может быть достигнуто путем многократного запроса одного и того же ресурса, метод, известный как опрос (polling).

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

При таком подходе, чем чаще клиент делает запросы (опросы) (requests (polls)), тем ближе он к общению в режиме реального времени. Если клиент проводит опросы каждый час, то в худшем случае может возникнуть задержка в один час между изменением, происходящим на сервере, и тем, когда клиент узнает об этом. Вместо этого проводите опрос каждую минуту, а клиент и сервер эффективно синхронизируются, и фактически всегда будут на связи.

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

Long polling (Длинный опрос)

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

Одна из оптимизаций, основывающаяся на опросе, называется длительным опросом (long polling). При длительном опросе используется та же идея, что и при повторном запросе обновлений клиентом к серверу, но с изюминкой: сервер не отвечает немедленно. Вместо этого сервер ждет, пока что-то изменится, а затем отвечает обновлением.

Давайте вернемся к приведенному выше примеру опроса, но на этот раз с сервером, который использует трюк с длинным опросом.

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

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

Webhooks (веб-перехватчики)

Когда опрос был исключен, некоторые разработчики инновационного программного обеспечения подумали: «Если все наши проблемы в том, что запросы делает только клиент, почему бы не отменить это правило?» Что они и сделали. Результатом стали webhooks — технология, при которой клиент одновременно отправляет запросы и прослушивает их, позволяя серверу легко отправлять на него обновления.

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

Давайте рассмотрим основы webhooks. В своей простейшей форме webhooks требует, чтобы клиент предоставлял URL-адрес обратного вызова, по которому он может получать события, а на сервере было место, где пользователь мог бы ввести этот URL-адрес обратного вызова. Затем, всякий раз, когда что-то меняется на сервере, сервер может отправить запрос на URL обратного вызова (callback) клиента, чтобы сообщить клиенту об обновлении.

Для нашей пиццерии процесс может выглядеть примерно следующим образом.

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

Subscription webhooks (Подписка вебхуков)

Основываясь на идее вебхуков, было множество решений, которые направлены на то, чтобы сделать процесс настройки динамичным и не требовать от человека ручного ввода URL обратного вызова на сервере. Вы могли слышать такие названия, как HTTP Subscriptions Specification (спецификация HTTP-подписок), Restful Webhooks, REST Hooks и PubSubHubbub. Все эти решения пытаются определить процесс подписки, в котором клиент может сообщить серверу, какие события его интересуют и на какой URL обратного вызова отправлять обновления.

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

Веб-хуки, основанные на подписке (Subscription-based webhooks), являются многообещающими. Они эффективны, работают в режиме реального времени и просты в использовании. Как и в случае со стремительным внедрением REST, это движение набирает обороты и становится все более распространенным, таким образом API-интерфейсы все чаще поддерживают те или иные формы веб-хуков.

Тем не менее, в обозримом будущем, скорее всего, найдется место для опроса (polling) и длительного опроса (long polling). Не все клиенты могут также выступать в качестве серверов. Смартфоны — отличный пример, где технические ограничения исключают возможность использования веб-хуков. По мере развития технологий будут появляться новые идеи о том, как упростить коммуникацию в реальном времени между всеми типами устройств.

Краткое изложение главы 7

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

Ключевые термины, которые мы узнали:

Опрос (Polling): Повторный запрос ресурса с коротким интервалом

Длительный опрос (Long polling): Опрос, но с отложенным ответом; повышает эффективность

Веб-перехватчики (Webhooks): Когда клиент дает серверу URL-адрес обратного вызова, чтобы сервер мог публиковать обновления в режиме реального времени

Подписка Веб-перехватчиков (Subscription webhooks): Неофициальное название для решений, которые делают настройку веб-перехватчиков автоматической

Следующая

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

Предыдущая глава:

Глава 6: Проектирование API

Следующая глава:

Глава 8: Реализация API

ссылка на оригинал статьи https://habr.com/ru/articles/891742/