По мнению аналитиков Forrester, цифровое связывание (digital bonding) — это эффективный механизм выхода за рамки границ предприятия с помощью интерфейсов прикладного программирования (API), сообщает портал ComputerWeekly.

Как известно, API расширяют экосистемы и присутствие на рынке таких крупных сервисов, как Google Maps и Lyft, а также создают новые рыночные каналы и продукты для традиционных игроков, включая Pitney-Bowes (информационные услуги, связанные с местоположением), Capital One (банковские счета, предложения по кредитным картам, вознаграждения и т. д.), Chicago Transit Authority (отслеживание транспорта и оповещения) — и многих других.

Причина, по которой корпоративные архитекторы реализуют подход REST (REpresentational State Transfer, передача состояния представления) для создания API, заключается в том, что REST помогает расширять экосистемы, увеличивать присутствие на рынке и создавать новые продукты, потоки доходов и каналы вовлечения.

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

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

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

Цифровое связывание за рамками REST

Цифровое связывание включает в себя как новые, так и традиционные механизмы соединения через границы предприятия. Предшественники REST, включая B2B-порталы, EDI, SOAP API и MFT, все еще в игре.

К более новым вариантам, которые выходят за рамки возможностей REST, относятся протокол WebSockets и язык GraphQL. WebSockets обеспечивает двустороннюю потоковую связь между компонентами ПО, позволяя передавать в реальном времени различные потоки информации, события, фильтрованные потоки данных и многое другое. GraphQL обеспечивает доступ на основе запросов к коллекции связанных схем данных, позволяя пользователям API перемещаться по данным так, как им хочется.

Важно отметить, что обе эти технологии получают поддержку — хотя и медленно — со стороны решений для управления API и API-шлюзов. Также наблюдается рост публикации событий по таким протоколам, как WebSockets и webhooks, и на брокерах, таких как Apache Kafka. Первопроходцы, добавляющие WebSockets в свои стратегии цифрового связывания, включают рыночные данные и обмен сообщениями, в то время как GraphQL имеет более широкое вертикальное применение.

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

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

Другим примером является то, как множество провайдеров предоставляют через WebSockets рыночные и криптовалютные данные. Одним из таких поставщиков является компания Refinitiv со своими платформами рыночных данных Enterprise Platform и Elektron Real Time in Cloud. Она поддерживает WebSockets как для доставки, так и для размещения рыночных данных.

Для криптовалют разработчики подключаются к WebSocket-каналу Kraken или Coinbase, выбирая определенные каналы для доступа к различным потокам данных по ордерам и сделкам. Это позволяет разработчикам подписываться на данные по конкретным валютам и создавать/вести книги ордеров — и все это даже без авторизации на сервисе. Кроме того, Coinbase позволяет разработчикам просматривать отдельные ордера по мере их размещения и аутентифицироваться на сервисе для получения более глубоких данных о собственных ордерах и сделках. Аналогичные WebSockets-каналы предлагают Gemini Trust Company, CEX.IO и другие компании.

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

Все они обеспечивают гибкий доступ к каким-либо базам данных. Для Deutsche Bahn и Helsinki Regional Transport Authority это данные общественного транспорта (например, расписания, маршруты). Для путешествий и развлечений — TravelgateX, Universe и Yelp. Геоданные (например, GraphLoc, Countries List), данные о здоровье (например, HIVdb Стэнфордского университета), химические реакции (например, Catalysis Hub), инструменты разработки (например, GitHub, GitLab), профессиональные данные (например, Mattermark, LeanIX) и архивы Холокоста (например, EHRI). Braintree выходит за рамки доступа к данным только по запросам и предоставляет через GraphQL платежные операции, как и commercetools и Shopify для покупательских корзин и других данных электронной коммерции.

WebSockets и GraphQL — это только начало пути за пределы REST. В дополнение к традиционным механизмам, корпоративные архитекторы, разрабатывающие стратегии цифрового связывания, могут обратить внимание на новые и развивающиеся механизмы, такие как Web Components, на основе событий (например, AsyncAPI, CloudEvents) и потоковой передачи данных. Некоторые механизмы могут включать новые технологии или протоколы, некоторые могут использовать старые технологии по-новому (например, обмен сообщениями между приложениями, MQTT), а некоторые могут быть шаблонами для использования REST API.

AsyncAPI становится все более популярным инструментом цифрового связывания

Использование интеграций на основе событий растет в связи с необходимостью устранения ограничений синхронных интеграций вызовов и ответов. Согласно данным Forrester за 2022 г., 26% разработчиков отмечают, что их организации уделяют большое внимание событийно-ориентированной архитектуре, — по сравнению с 20% в 2021-м. AsyncAPI становится все более популярным способом описания событийно-ориентированной интеграции, подобно тому, как вы используете Open API Spec (ранее Swagger) для документирования REST.

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

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

Расширение взглядов на интеграцию

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

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

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

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