Application Programming Interface (API)

API как средство интеграции приложений

API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.

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

Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.Как создать ПО для технологического моделирования на замену западному совместно с партнёрами. Опыт «СИБУРа» представлен на TAdviser SummIT 26.2 т

По такому принципу построены протоколы передачи данных по Internet. Стандартный протокол Internet (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи пакетов бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему уровню.

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

API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.

Application Programming Interface (API) программный интерфейс взаимодействия между системами, позволяющий:

• Получать доступ к бизнес-сервисам предприятия
• Обмениваться информацией между системами и приложениями
• Упростить взаимодействие между компаниями, партнерами, разработчиками и клиентами

Open API стратегия

API стратегия включает в себя:

• Разработку бизнес-продуктов на основе существующих API
• Предоставление внутренних сервисов разработчикам
• Модели монетизации API для построения мультиканального взаимодействия и повышения прибыли

Реализация концепции Open API помогает трансформировать бизнес, встраивать его в гибкую проектную экосистему игроков рынка, создавать условия для постоянной генерации новых идей и формирования дополнительной ценности при управлении массивами корпоративных данных.

Рынок интеграционных решений развивается в контексте эволюции API - от EDI и SOAP до Web 2.0, с которого началась эра публичных API. Число таких интерфейсов в ближайшие 3 года может вырасти более чем в 50 раза и достичь 1 миллиона. Это связано с мультиканальностью: каналы взаимодействия с клиентами должны меняться вместе с ними. Непрерывный рост количества потребителей и объема данных привел к появлению экономики API, помогающей на основе открытых интерфейсов создавать инновационные бизнес-модели использования корпоративных активов и сервисов.

Сигнатура функции

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

Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.

Например, в языке программирования Си++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет учаcтвовать и имя класса.

В языке программирования Java сигнатуру метода составляет его имя и последовательность типов параметров; тип значения в сигнатуре не участвует.

Семантика функции

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

Основные типы API

Внутренние API

• Доступ к API предоставляется только внутренним разработчикам
• Приложения нацелены на сотрудников предприятия

Бизнес-драйверы:

• Консистентность разработки
• Снижение затрат
• Повышение эффективности разработки

Партнерские API

• API доступны только ограниченному набору бизнес-партнеров
• Приложения предназначены для конечных потребителей и для бизнес-пользователей

Бизнес-драйверы:

• Автоматизация процесса разработки
• Развитие партнерских отношений
• Оптимизация процесса взаимодействия с партнерами

Публичные API

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

Бизнес-драйверы:

• Разработка новых сервисов
• Развитие экосистемы
• Мультиканальное взаимодействие

API для облачного хранения

Интерфейсы прикладного программирования (application programming interfaces, API) для связи облачных хранилищ с приложениями бывают различных типов. . На объединении данных из различных онлайн-источников строится огромное количество веб-контента. Когда-то давно эту комбинацию называли «мэшапами» или «Интернет 2.0», но сегодня веб-приложения стало частью современного мира ИТ. Ниже рассмотрены API управления хранилищем, которые разработчики могут использовать для предоставления услуг хранения веб-приложениям^[1].

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

API для хранения данных можно разделить на несколько категорий, включая:

• API, которые подключаются к облачным сервисам синхронизации файлов и облачным дискам, а также к приложениям для повышения продуктивности, таким как Google Workspace или Microsoft 365 через Graph API;
• API для подключения веб-приложений к службам хранения данных облачных провайдеров;
• API, позволяющие использовать сервисы, связанные с хранением данных, такие как базы, озера и хранилища данных.

В каких случаях используются API для хранения данных

При подключении через API к сервисам, таким как облачные диски, приложения для повышения продуктивности и т. п., имеется в виду возможность создавать, читать, обновлять и удалять (create, read, update and delete, CRUD) данные, обычно с помощью HTTP-методов, таких как Get, Post, Put и т. д. Это сценарии, которые больше всего подходят для СМБ. На начальном уровне для доступа к файлам, э-таблицам, э-почте, документам, календарям, аналитике можно подключаться к таким службам, как Google Workspace или Microsoft 365.

Кроме того, через API можно подключаться к облачным хранилищам провайдеров — обычно объектным, — чтобы использовать данные и управлять ими в соответствии с бизнес-сценарием. В корпоративном сегменте также существует широкий спектр сервисов данных, доступных через API. К ним относятся базы данных (SQL и NoSQL), а также сервисы более высокого уровня, часто основанные на них, такие как озера и хранилища данных.

Кто предоставляет API для хранения данных и сколько они стоят

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

Microsoft Graph — это платформа API для разработчиков, которая позволяет получить доступ к широкому спектру продуктов Microsoft. Компания предлагает разработчикам бесплатную учетную запись 365. После этого стоимость зависит от количества объектов Graph, к которым осуществляется доступ. На данный момент она составляет 0,375 долл. за 1000 объектов.

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

Доступ к хранилищам основных облачных провайдеров — AWS, Microsoft Azure и Google Cloud — по сути, основан на API, причем используются команды Rest и HTTP. Доступ к объектным хранилищам гиперскейлеров, таких как Amazon S3 и Azure Blob, осуществляется с помощью привычных API-методов для операций CRUD.

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

Доступ к базам данных, например, AWS RDS (SQL) и DynamoDB (NoSQL), также осуществляется через API. Аналогично можно сказать про Azure SQL Database и Cosmos DB, а также NoSQL Cloud SQL и Datastore, которые предлагает Google. Кроме того, в облаках большой тройки гиперскейлеров можно использовать базы данных MongoDB, Scylla и PostgreSQL. У всех облачных провайдеров есть бесплатный уровень, но он предназначен для небольших компаний и разработчиков.

Fauna, DataStax, Couchbase и MongoDB Atlas предлагают нечто похожее на облачные точечные решения баз данных, иногда стилизованные под DBaaS (и обычно NoSQL). Помимо этого, большой тройкой предлагаются доступные через API более сложные решения — озера и хранилища. К ним относятся Azure Data Lake, Amazon Redshift и Google BigQuery.

API операционных систем

• Windows API
• POSIX
• Linux Kernel API
• OS/2 API
• Amiga ROM Kernel

Практически все операционные системы (Unix, Windows, MacOS, и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.

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

С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов Qt, Gtk, и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin, и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека [[Си языка C), написания интерпретируемых языков, реализуемых на разных платформах (sh, perl, php, tcl, Java, и т. д.)

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

Например: для того, чтобы увидеть в браузере строчку «Hello, world!» достаточно лишь создать HTML-документ с минимальным заголовком, и простейшим телом, содержащим данную строку. Что произойдёт, когда браузер откроет этот документ? Программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл, и разберётся в его устройстве, повызывает через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать выбранным шрифтом Hello, world!», при этих операциях библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы с запросами вида «а положи-ка мне в буфер видеокарты вот это».

При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные HTML-библиотеки, и, кроме того, всё это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.

Основными сложностями существующих многоуровневых систем API, таким образом, являются:

• Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
• Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.

API графических интерфейсов

• GDI
• GDI+
• Direct3D (часть DirectX)
• DirectDraw (часть DirectX)
• OpenGL
• OpenVG
• X11
• Qt
• GTK
• Motiff
• Tk
• Zune
• SDL

API звуковых интерфейсов

• DirectSound (часть DirectX)
• DirectMusic (часть DirectX)
• OpenAL

API аутентификационных систем

• BioAPI
• PAM

Принцип и использование API Economy

Магический квадрант Gartner для Full Life Cycle API Management, октябрь 2016 г.

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

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

Чем же руководствоваться на практике? В нескольких исследовательских заметах Gartner даются следующие подсказки^[2].

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

Принцип API Economy

Использование API открывает новые возможности взаимодействия с экосистемой

API позволяют организациям создавать персонализированное взаимодействие с пользователем

Ожидания и поведение покупателей меняются^{[3] [4]}

Покупатели:

• Требуют индивидуализированного подхода –на их условиях
• Ожидают комплексного интегрированного обслуживания
• Перейдутк любому, кто лучше удовлетворит их требования

Организации:

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

API везде!

• По оценкам экспертов, к концу десятилетия пользователям будет доступно более 1 миллиона публичных API^[5]
• По статистике, более 9 миллионов разработчиков вовлечены в создание внутренних API. Сегодня фокус сдвигается в сторону разработки публичных API^[6]
• Интернет вещей (IoT) достигнет 20 миллиардов подключенных устройств к 2020 году^[7]
• Google в 2016 году заплатила 625 млн. долл. за покупку поставщика платформы управления API фирмы Apigee.
• Как рассказал руководитель центра консалтинга Aplana Амелин Владимир, в 2016 году число опубликованных Public API во всем мире достигло 16 тыс., а к 2020 г. их будет уже более 1 млн. В России их предоставляют «Яндекс», Mail.ru, «ВКонтакте», «Одноклассники», в финансовой сфере — Сбербанк, ФК «Открытие», «Тинькофф Банк», ВТБ, а также крупные розничные сети, сервисы госуслуг и открытого правительства. Согласно проведенному опросу, 26% отечественных банков разработали или разрабатывают собственные API, еще 38% планируют сделать это в следующем году. По данным Gartner, 75% банков из мирового списка Top 50 уже имеют собственные открытые API, а к 2018 г. регуляторы половины стран G20 примут стандарты, регулирующие их применение. Разновидностью Public API являются интерфейсы категории Open API, базирующиеся на открытых стандартах и доступные широкому кругу разработчиков, как правило, на бесплатной основе. По словам Владимира Амелина, рост их популярности связан с тем, что все больше компаний видят в них потенциал для развертывания новых бизнес-моделей и понимают, как такие модели монетизировать.

Мировой рынок API

Данные 2020 года, далее - прогноз

Хронология событий

2023: Российские операторы связи за год заработали 5,8 млрд рублей на API (+26%)

По итогам 2023 года объем российского рынка программных интерфейсов (API) в области телекоммуникаций достиг 5,8 млрд рублей. Это на четверть — 26% — больше по сравнению с 2022-м, когда затраты в данном сегменте оценивались в 4,6 млрд рублей. Такие данные отражены в обзоре компании «ТМТ Консалтинг», опубликованном 10 октября 2024 года.

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

• Стремление компаний к омниканальности и персонализации общения с клиентами;
• Расширение рынка российского ПО в целом на фоне ухода либо ограничения присутствия зарубежных игроков;
• Автоматизация и роботизация каналов общения;
• Борьба со спамом, развитие средств защиты персональных данных;
• Внедрение аналитических инструментов и речевых технологий на базе искусственного интеллекта;
• Увеличение числа интеграций с бизнес-системами;
• Развитие рынка облачных коммуникационных платформ (CPaaS).

В структуре доходов по услугам в 2023 году лидировали сервисы маскировки номеров с долей около 26% в общем объеме рынка. Далее идут интерактивное голосовое меню (IVR) и обработка входящих вызовов с 23%, а также интеллектуальная маршрутизация вызовов, обеспечившая 15% дохода. На облачные решения для контактных центров пришлось 13%, на управление нумерацией — 6%. Еще 8% обеспечили службы CallBack, 6% — запись и аналитика разговоров, 3% — Calltracking.

Таким образом, основной объем выручки формируют четыре услуги, на которые приходится 77% доходов. Ключевыми факторами спроса на сервисы маскировки номеров являются востребованность сохранности базы данных клиентов и функций по защите номера, повышающих уровень конфиденциальности для пользователей финансовых платформ, крупнейших маркетплейсов и агрегаторов такси. Росту сегмента IVR и обработки вызовов способствуют развитие интеграции сервиса с CRM и другими бизнес-системами, внедрение ИИ, внедрение речевых аналитических инструментов, автоматизация рутинных процессов в компаниях. Интеллектуальная маршрутизация востребована в быстрорастущих отраслевых сегментах, таких как службы доставки и электронная коммерция. Кроме того, ее популярности способствует возможность оптимизации работы внутренних структур компаний-пользователей (отделов продажи, управления персоналом, клиентского сервиса, поддержки). Развитие рынка облачных решений для контакт-центров обеспечено расширением функциональности услуги, обогащением сервисами, а также увеличением бизнес-активности и переходом части клиентов с зарубежных решений на отечественное ПО.

Лидером рынка по итогам 2023 года является компания МТС Exolve, занимающая первые позиции в большинстве исследуемых продуктовых сегментов, за исключением сектора «Управление нумерацией», где лидирует компания «Интернод» (владелец брендов Runexis и «Плюсофон», предоставляющий в аренду телефонные номера), и сферы «Облачные решения для КЦ», где первое место принадлежит компании Voximplant, активно развивающей данное направление. Общая доля МТС Exolve составила 47%. На втором месте располагается Voximplant с 15%, а замыкает тройку «билайн» с результатом в 7%.^[8]

2022: Развитие открытых API в России позволит создать условия для появления инновационных сервисов и бизнес-моделей

Ассоциация ФинТех 14 февраля 2022 года представила результаты исследования по вопросам применения Открытых API на российском финансовом рынке «Области стандартизации Открытых API и обязательность их публикации участниками рынка финансовых услуг России». Документ был подготовлен совместно с международной консалтинговой компанией Accenture.

В рамках исследования были поставлены следующие задачи:

• приоритизировать области применения Открытых API для разработки стандартов;
• определить подход к обязательности и рекомендательности предоставления API участниками рынка;
• определить необходимые условия для внедрения стандартов Открытых API с учетом как мировой практики, так и мнения участников рынка.

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

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

Открытые API могут способствовать развитию большого спектра новых решений по ряду направлений, например:

• обмен информацией о клиенте (с согласия клиента) и его учетной записи — для новых сервисов по управлению финансами в «едином окне» (PFM-сервисы), персонализации предложений и принятия кредитных решений;
• сравнение и выбор финансовых продуктов на платформах-агрегаторах и маркетплейсах;
• «встраивание» финансовых сервисов и услуг в платформы третьих сторон;
• бесшовные платежи и операции с финансовыми продуктами через платформы третьих сторон;
• идентификация и знания о клиенте «как-сервис» для финансовых организаций.

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

С полной версией исследования можно ознакомиться здесь.

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

Для целей данного исследования был проведен опрос 1000 физических лиц и 500 представителей компаний малого и среднего бизнеса в 85 регионах, глубинные интервью и открытый опрос 70 участников финансового рынка (банков, страховых и инвестиционных компаний, МФО, НПФ и финтех- игроков)

2021

SWIFT опубликовал доклад о потенциале API

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

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

Первый API был запущен SWIFT в 2017 году, в 2020 году через SWIFT было совершено более двух миллиардов операций API. Это на 120% больше, чем в 2019 году. На портале для разработчиков SWIFT доступно 20 инновационных API. SWIFT также сотрудничает с надежными сторонними поставщиками из своего сообщества, которые могут предлагать услуги пользователям через канал SWIFT API.

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

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

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

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

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

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

SWIFT находится в поиске единых бизнес-стандартов для обеспечения совместимости API для финансовых операций. Мировое финансовое сообщество находится на пути к принятию стандарта ISO 20022 для трансграничных платежей к ноябрю 2025 года. Регуляторы требуют от финансовых учреждений использования унифицированных API для обеспечения функциональной совместимости продуктов и услуг. И SWIFT предлагает стандартизированный подход к API, который основывается на моделях потребления и данных, идентификации, аутентификации и спецификации Open API.

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

Безопасность API становится наивысшим приоритетом для предприятий

Как следует из результатов исследования Imvision «API Security is Coming»^[9], по мере роста числа атак на интерфесы прикладного программирования (API), безопасность, связанная с их внедрением и использованием, вызывает все больше беспокойства у руководителей организаций, сообщает портал ZDNet^[10].

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

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

Imvision опросила более 100 специалистов по кибербезопасности в США и Европе, чтобы получить представление о текущем состоянии безопасности API на предприятиях. Согласно отчету, 91% респондентов считают, что безопасность API должна стать приоритетом в ближайшие два года, особенно с учетом того, что более 70% корпоративных организаций, по оценкам, используют более 50 API.

Основными аспектами безопасности API респонденты считают контроль доступа (63% опрошенных), регулярное тестирование (53%), а также обнаружение и предотвращение аномалий (43%). В общей сложности, 8 из 10 ИТ-администраторов хотят иметь больше контроля над API своей организации.

Однако поиск целостного подхода к безопасности API остается сложной задачей. Более 80% организаций, по оценкам, либо используют, либо планируют использовать решение для централизованного управления безопасностью API — например, платформу API Management (APIM), — но лишь треть опрошенных считают, что настройки их API адекватно защищают их от современных кибератак.

Другие статистические данные, отмеченные в отчете:

• 19% предприятий ежедневно тестируют свои API на наличие признаков злоупотребления;
• 4 из 5 организаций позволяют партнерам или пользователям получать доступ к данным с помощью внешних API;
• в настоящее время API-стратегии сосредоточены на производительности приложений (64%) и разработке и интеграции (58%);
• теневые API считаются наиболее уязвимыми, считают 40% опрошенных;
• 64% опрошенных сказали, что их текущие решения не обеспечивают надежную защиту API.

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

2019

Исследование TAdviser совместно с ПАО «Банк ВТБ» при участии Сколково: В банковском секторе России начинается API-трансформация

Опрос 25 банков, входящих в топ-100 крупнейших финансовых организаций российского рынка, показал, что 75% из них уже начали или планируют использовать открытые API. Более 70% банков ожидают от регулятора разработки стандартов и рекомендаций в этой области. Препятствуют развитию API риски утечки конфиденциальных данных и опасения, связанные с неправомерным использованием открытой информации. Российские ИТ-компании обладают необходимыми компетенциями и готовы помочь банкам провести API-трансформацию.

Основная статья: В банковском секторе России начинается API-трансформация

ЦБ пригласил около 20 банков к участию в пилоте в сфере открытых API

21 августа 2019 года стало известно о том, что Банк России выступил координатором пилотного проекта в сфере открытых API (программных интерфейсов приложений) для интеграции сервисов банков в рамках Евразийского экономического союза (ЕАЭС). На момент выпуска материала ЦБ совместно с центральными банками стран ЕАЭС проводит работу по подготовке пилота к реализации. Об этом «Коммерсанту» рассказали банкиры, получившие предложение Центробанка. Всего письмо регулятора получили около 20 кредитных организаций, которые должны дать ответ о готовности к участию до 23 августа. Подробнее здесь.

Индустрия ценных бумаг готова к API

2 августа 2019 года стало известно, что совместное исследование SWIFT и BCG выявило рост использования API на фоне стремления компаний к повышению эффективности и предложению услуг.

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

Согласно опросу BCG, только в течение 2018 года осведомленность об API среди управляющих активами увеличилась на 26% (с 46% до 72%). Растущий коммерческий интерес стимулирует пилотные схемы и сценарии применения, особенно между управляющими компаниями и их кастодианами.

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

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

В индустрии ценных бумаг внедрение API происходит медленнее, чем в других сферах финансовых услуг частично из-за отсутствия нормативно-правовой базы и недостаточной последовательности в готовности игроков рынка принять API. Компании по управлению активами существенно различаются по своей технической оснащенности и открытости для взаимодействия с провайдерами через API. Около 56% респондентов в опросе BCG считают уровень внедрения API в посттрейдинге «экспериментальным», в то время как всего лишь 21% говорят, что он «высокий» или «средний».

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

В отчете приводится четыре причины, по которым индустрии стоит внедрять API:

• Взаимодействие в рамках общей инфраструктуры. Такие фундаментальные элементы API-решений, как удостоверение личности, аутентификация, безопасность и управление сетевыми соединениями, должны согласовываться на отраслевом уровне, а не между отдельными фирмами.
• Координация стандартов API для поддержания совместимости. Распространение множества стандартов может снизить эффективность использования API. Индустрия нуждается в едином стандарте API, который будет работать между всеми провайдерами.
• Поддержка сетевых API, а не p2p-решений. Фирмы могут извлекать выгоду от сетевых API: например, один вызов для проверки статуса расчета от брокера-дилера может быть направлен нескольким кастодианам одновременно. Сетевое решение будет поддерживать конвергенцию как для объяснения данных, так и для других характеристик API.
• Соответствие строгим стандартам безопасности и устойчивости. Для успешного развития любое API-решение должно иметь высокий уровень защиты данных и устойчивости.

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

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

API европейских банков оказались не готовы к выполнению требований PSD2

10 июля 2019 года стало известно, что на фоне стремительного приближения даты вступления в силу нормативных технических стандартов (Regulatory Technical Standards, RTS), лежащих в основе Директивы PSD2, представители шведской открытой банковской платформы Tink заявляют, что европейским кредитным институтам не удалось обеспечить сторонним поставщикам технологическую среду, необходимую для доступа к платежным данным, как того требует вышедший закон. Подробнее здесь.

Смотрите также

• Открытые данные
• Software Development Kit (SDK)