Различия между API и обменом сообщениями с точки зрения взаимодействия между приложениям

Фил Уилкинс (Phil Wilkins) | Евангелист облачной разработки, Oracle | декабрь 2022 г.

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

Существует два типичных механизма такого взаимодействия: прикладные программные интерфейсы (API) и обмен сообщениями.

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

Подробное определение API

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

Звучит просто? Да, но только на одном уровне. На практике значение термина «API» может меняться в зависимости от темы разговора. Согласно аббревиатуре, API — это интерфейс или контракт, с помощью которого один программный компонент может взаимодействовать с другим программным компонентом. Иногда описание API сосредоточено на его высокоуровневых архитектурных определениях, а иногда это детализированное изложение конкретных способов реализации API разработчиками.

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

Что делает API на высоком уровне? В нашей аналогии с дверью он открывается, чтобы посетителю не приходилось останавливаться и чего-либо касаться (дверь супермаркета), или ограничивает доступ и защищает то, находится что за дверью (банковское хранилище)?
Какие передаваемые между программными компонентами данные (полезные данные) он должен поддерживать, чтобы программное обеспечение выполняло свою работу? Например, программное обеспечение может получать номер банковского счета и авторизацию системы безопасности, после чего отправлять в ответ остаток на этом банковском счете.
Какими данными нужно обменяться для оказания этой услуги? Например, нужно точно определить, как выглядят действительный номер счета и авторизация системы безопасности, а также определить содержимое ответа. Здесь очень важны детали; неопределенность может привести к ошибкам.
Какой у двери адрес? Обычно это означает, как формируется универсальный идентификатор ресурса (URI) для запроса. Иными словами, как инициатор запроса на самом деле «разговаривает» с API?
Какие протоколы будут использоваться для этой коммуникации? В их качестве могут выступать как широко известные технологий, такие как HTTP и FTP, так и специализированные протоколы, такие как STOMP и QUIC.
Какие условия должен соблюдать пользователь API? Условия могут включать в себя требования к шифрованию, ограничение на частоту вызова API или механизмы возврата платежей (для коммерческих сервисов).
Какие обещания дает API? К обещаниям могут относиться гарантии уровня обслуживания API, например выполнение или подтверждение принятия запроса в течение определенного периода времени.

Определение обмена сообщениями в разработке приложений

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

Попробуйте представить себе это следующим образом:

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

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

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

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

Дополнительные подробности о составе API, платформ API и механизмов управления API можно узнать здесь.

Сочетание API и обмена сообщениями в корпоративных системах

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

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

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

Синхронное и асинхронное поведение

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

Сложные системы обмена сообщениями в корпоративной среде бывают разных видов и схем:

Сервисная шина. Сервисная шина служит связующим звеном между различными процессами и обеспечивает координацию этих процессов, например как в упомянутой выше сложной транзакции. Сервисные шины обычно выполняют также дополнительные функции, такие как перевод полезных данных из одного формата в другой (с английского на французский в нашей аналогии с SMS), маршрутизация сообщений на основе содержимого сообщения или даже принятие некоторых решений на основе состояния сложной транзакции. Например, задачи А и Б можно выполнять параллельно; выполнить задачу В, если задача Б выполнена успешно; если выполнить задачу Б не удалось, выполнить задачу В; если выполнить задачу В не удалось, потребовать вмешательства человека.

Обмен сообщениями по принципу сервисной шины иногда описывается как использование умной трубы из-за этой дополнительной интеллектуальной обработки — маршрутизации и планирования сообщений в «трубе» между поставщиками и потребителями. Также это называется оркестрацией.

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

Синоним сервисной шины —шина сообщений. На ранних этапах эволюции этих технологий, когда они нашли свое воплощение в решениях сервис-ориентированной архитектуры (SOA), существовали некоторые различия между шинами сообщений и сервисными шинами. На сегодня реальных различий между ними нет, и название все чаще сокращают до просто шины.
Веб-сервисы. В самом широком смысле этого слова веб-сервисы представляют собой прямое синхронное взаимодействие между двумя процессами, обычно по протоколам TCP и HTTP (или их вариантам, таким как HTTPS и HTTP/2). Потребитель и клиент реализуются как подключения «точка-точка» (хотя довольно часто поставщик поддерживает несколько параллельных подключений клиентов). Между двумя процессами могут быть прокси (от сетевых брандмауэров до шлюзов API и веб-кэшей) и сетевые посредники (коммутаторы и маршрутизаторы), но ни поставщик, ни потребитель не будут знать об их существовании.
Поставщик сообщений взаимодействует непосредственно с потребителем. Процесс передачи зависит от доступности обеих сторон.
Брокеры сообщений. Брокеры сообщений — это посредники между поставщиком сообщений и потребителем сообщений. Они имеют общие черты как с сервисными шинами, так и с веб-сервисами.

Брокеры, находящиеся между отправителем и получателями сообщений, получают передаваемое сообщение и сохраняют его до тех пор, пока получатели его не потребят. Это означает, что сообщение будет передано даже в случае, если получатель в данный момент недоступен. В результате этот вид связи часто описывается как асинхронный или «выстрелил и забыл», потому что Вы можете быть уверены, что сообщение когда-нибудь будет доставлено, — при условии, что брокер не прекратит свою работу.

Сходство с веб-сервисами заключается в том, что соединение между клиентом и брокером представлено как подключение «точка-точка»; брокер сообщений функционально невидим.

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

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

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

Роль потоковой передачи в корпоративном обмене сообщениями

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

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

К распространенным технологиям потоковой передачи для веб-служб относятся WebSockets, потоки gRPC и подписки GraphQL. Если речь идет о потоках сообщений через брокеров (при использовании таких технологий, как Kafka), иногда можно использовать особенности работы брокера для просмотра «среза» передаваемых событий. Это позволяет собирать ценную информацию, включая информацию о самом потоке, — отсюда термин потоковая аналитика.

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

API и отраслевые стандарты обмена сообщениями

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

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

При использовании API (и потоковой передачи) существует ряд дополнительных стандартов для определения и описания аспектов сообщений и их передачи. К ним относятся буферы протоколов (также называемые Protobuf и используемые в сочетании с gRPC) и, в последнее время, GraphQL, схема JSON и YAML.

В сфере асинхронного обмена сообщениями в последние годы наблюдается объединение вокруг определения под названием AsyncAPI, в котором используются адаптированные идеи из OpenAPI и других развивающихся стандартов для решения многих задач обмена сообщениями.

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