ИНФОРМАЦИОННЫЙ ТРЭВЕЛ - ПОРТАЛ

API – ИНСТРУМЕНТ РЕАЛЬНОГО ВРЕМЕНИ

 

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

 

Важный компонент IT-архитектуры 

По сути, API представляет собой один из механизмов обмена данными и/или совместного использования дистрибутивных функций деловыми партнерами в авиационной отрасли. Этот интерфейс обеспечивает работу многих современных мобильных и веб-приложений, предоставляя разработчикам набор функций, структур и констант (данные и/или бизнес-логику). Разработчики используют эту функциональность для создания программных модулей, необходимых авиакомпаниям для выполнения задач дистрибуции продуктов и услуг, а также для взаимодействия с другими отраслевыми субъектами.

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

Веб-интерфейсы API становятся неотъемлемой частью IT-архитектуры авиапредприятий, обеспечивая интеграцию на основе различных платформ и концепций, включая SOA (Service Oriented Architecture – Интеграция сервисных приложений), EAI (Enterprise Application Integration – Интеграция корпоративных приложений), ESB (Enterprise Service Bus — Интеграция корпоративных приложений и служб для сложных архитектур) и даже ETL (Extract Transform Load – Извлечение данных из внешних источников, их трансформация и очистка в соответствии с потребностями бизнес-модели и загрузка их в хранилище данных). Следует отметить, что различия между этими понятиями сейчас довольно размыты на фоне разных действующих платформ, предназначенных для экосистем данных, приложений и источников данных как в локальных, так и в облачных компьютерных средах, включая MuleSoft, Boomi и Informatica. Как правило, эти интеграционные платформы поддерживают функцию преобразования сообщений, маршрутизацию и совместимость разных API.

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

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

 

Подходы и форматы 

Лоукостеры широко используют API для своих систем дистрибуции, в то время как сетевые перевозчики предпочитают смешанную модель, в которой велика доля традиционных дистрибутивных каналов. При этом все больше авиакомпаний теперь берут на вооружение Новую дистрибутивную модель IATA NDC и на ее основе создают API для систем поиска рейсов, бронирования и тикетирования. Эталонная архитектура (Reference Architecture, то есть обобщенная архитектура нескольких конечных систем, которые относятся к одной или нескольким общим предметным областям) на уровне NDC  является хорошим примером реализации модульной иерархии с помощью API.

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

Сегодня существует два основных подхода к Веб-API: для API B2C с низкой/средней степенью сложности предпочтительная архитектура RESTful (стиль  архитектуры программного обеспечения для построения  распределенных масштабируемых веб-сервисов, например, через Google, Facebook, Twitter или GitHub). По мнению  специалистов,  такие интерфейсы проще реализовать, чем наиболее распространенные аналоги, включая веб-сервис SOAP (Simple Object Access Protocol – простой протокол доступа к объектам). Однако, когда речь идет о внедрении сложных корпоративных В2В-системах, практика показывает, что предпочтительнее использовать SOAP, поскольку он является надежным и хорошо зарекомендовавшим себя сервисом, который обеспечивает надежную защиту данных. Хотя в последнее время за счёт тенденции Web 2.0 осуществлён переход от SOAP к REST типу коммуникации. Веб-интерфейсы, обеспечивающие сочетание нескольких сервисов в новых приложениях, известны как гибридные.

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

IATA в настоящее время изучает технические возможности внедрения  GraphQL в среде NDC.

Еще одним фактором, который необходимо учитывать при выборе технологий, является формат сообщения в канале обмена данными. Например, в случае SOAP необходимо использовать протокол XML. Другие форматы данных, такие как JSON (JavaScript Object Notation), также могут применяться в имплементациях RESTful API в среде NDC. Несмотря на то, что NDC сегодня определена как стандарт обмена сообщениями XML, она также обеспечивает поддержку разработчиков, работающих с JSON.

 

 

АвиаГоризонты, по материалам сайта IATA и отраслевой печати.    

 

Поделиться ссылкой: