Рори Бланделл, основатель и генеральный директор компании Gravitee, рассказывает на портале ITPro Today о том, как нативно-событийное управление API (event-native API management) решает проблемы, связанные с традиционными подходами к API-менеджменту.

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

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

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

Ограничения синхронных API

Традиционные API работают синхронно. Клиент делает запрос на получение данных, а сервер отвечает на него. Если клиент хочет получить обновленные данные, он должен сделать новый запрос, и сервер должен ответить снова.

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

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

Эра потоковых данных

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

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

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

Ограничения потоковой передачи данных

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

Существует множество решений — таких как Kafka и RabbitMQ, и это лишь пара популярных Open Source-вариантов, — которые позволяют передавать данные в пределах собственной ИТ-системы организации в виде потоков. Однако основное ограничение этих технологий заключается в том, что они не предназначены для передачи потоков данных во внешний мир. Другими словами, вы не можете безопасно сделать свой поток Kafka доступным вовне. И даже если вы проигнорируете риски безопасности, сам Kafka не обеспечит тонкий контроль, необходимый для определения того, как именно данные форматируются и изменяются при передаче внешним потребителям.

Появление Event-Native API Management

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

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

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

Event-Native API Management и будущее данных

Когда речь идет о будущем данных, очевидны две тенденции: объемы данных будут продолжать расти, а темпы их изменения будут ускоряться.

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