API

API открывает программную систему для внешних взаимодействий. Она позволяет двум программам обмениваться данными через границу — интерфейс, использующий согласованные сигналы^[3]. Иными словами, API связывает между собой программные сущности. В отличие от пользовательского интерфейса, API обычно скрыт от глаз пользователя: это часть системы «под капотом», предназначенная для обмена данными между машинами^[4].

Хорошо спроектированный API предоставляет только те объекты или действия, которые востребованы разработчиками, скрывая ненужные детали. Такая абстракция упрощает программирование^[5].

Разработка программного обеспечения с помощью API сравнивается со сборкой игрушек из строительных блоков, например, Lego. Программные сервисы или библиотеки подобны этим блокам: их можно соединять между собой через API — процесс называют интеграцией^[6][3].

Пример: погодный датчик с API. Когда к датчику отправляют определённое сообщение, он измеряет погодные условия и возвращает отчёт. Это сообщение — вызов API, ответ датчика — ответ API^[7]. Приложение для прогноза погоды может интегрироваться с несколькими такими API, получая данные с разных датчиков одного региона.

API часто сравнивают с контрактом: соглашение между провайдером услуги (API) и разработчиками, использующими его. Чем стабильнее API и предсказуемее его изменения, тем выше доверие и популярность среди разработчиков^[8].

Поначалу термин API означал интерфейс только для программ, взаимодействующих с конечным пользователем (прикладные программы), что отражено в названии — «интерфейс программирования приложений». В наши дни понятие расширено и охватывает утилиты и аппаратные интерфейсы^[10].

Концепция API возникла значительно раньше своего названия. Британские учёные Морис Уилкс и Дэвид Уилер уже в 1940-х разрабатывали модульную программную библиотеку для EDSAC. Подпрограммы библиотеки хранились на перфолентах в шкафу, где также лежал каталог с описаниями применения каждого модуля. Сегодня его бы назвали спецификацией или документацией API, потому что он объяснял, как «вызывать» нужную подпрограмму^[10].

Книга Уилкса и Уилера The Preparation of Programs for an Electronic Digital Computer содержит первую опубликованную спецификацию API. Джошуа Блох отмечает, что они «имплицитно изобрели» API, так как эта идея скорее обнаруживается, чем изобретается^[10].

Первое упоминание термина «application program interface» (без окончания «-ing») встречается в докладе о графических удалённых системах на конференции AFIPS в 1968 году^[10]. Авторы описывали единый интерфейс (на вызовах Fortran), стандартизирующий работу с графическими устройствами, что должно было избавить программиста от тонкостей конкретных устройств и обеспечить независимость ПО от аппаратных изменений^[11].

Термин перешёл и в область баз данных благодаря К. Дж. Дейту, который в 1974 году рассматривал API как отдельный интерфейс в системах управления базами данных^[12][13]. В ANSI-SPARC API выделен как самостоятельный интерфейс, параллельно с другими, например, языком запросов. Вскоре архитектуру стали строить не вокруг прикладного, а универсального API^[9].

К 1990 году API определялся как «набор сервисов для программиста»^[14].

С развитием удалённых вызовов процедур и Web API, использование API вышло за пределы локальных библиотек. В 1970-80‑х с развитием сетей программисты стали обращаться к библиотекам на других машинах. В 1990‑х распространились стандарты CORBA, COM, DCOM. Рой Филдинг в 2000 году в диссертации описал REST и сравнил сетевые API с классическими библиотечными интерфейсами^[15]. Массовое внедрение JSON/XML-API началось в 2000‑х^[2].

Тим Бернерс-Ли предлагал в 2001 году «семантические API» для открытых распределённых данных^[16]. С развитием интернета и распространённостью Web API термин API всё чаще используется для самых разных интерфейсов передачи данных; в этом значении он часто пересекается с термином протокол связи^[17].

В начале 2010-х годов архитектурный стиль REST окончательно утвердился в качестве отраслевого стандарта для создания веб-сервисов, вытеснив более сложный протокол SOAP^[18]. Его популярность была обусловлена простотой, основанной на стандартных методах HTTP (GET, POST, PUT, DELETE), и ростом мобильных и веб-приложений, которые нуждались в гибком способе обмена данными^[18][19].

К середине десятилетия, по мере усложнения приложений, стали очевидны ограничения REST, в частности проблемы избыточной (over-fetching) и недостаточной (under-fetching) загрузки данных^[20][19]. В ответ на это в 2012 году инженеры Facebook разработали язык запросов GraphQL для оптимизации работы новостной ленты мобильного приложения^[21]. После публичного релиза в 2015 году GraphQL начал набирать популярность как альтернатива REST^[22]. Ключевыми преимуществами GraphQL стали возможность запрашивать только необходимые данные одним запросом и строгая типизация^[22][23][24].

К концу 2010-х годов API из технических инструментов превратились в полноценные бизнес-активы, что привело к формированию концепции «API-экономики»^[25]. В этот период также получили развитие инструменты управления API (API gateways), концепция открытых API в финансовом секторе и государственных структурах, а также подход к разработке «API-first»^[25].

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

Подход «API-first», при котором проектирование и реализация API становятся отправной точкой всего проекта, начал приобретать статус стандарта^[26]. Суть методологии заключается в первоначальном создании «контракта» — спецификации API (часто с использованием OpenAPI), что позволяет командам фронтенда и бэкенда работать параллельно и независимо друг от друга^[26][27]. Такой подход повышает согласованность разработки и упрощает дальнейшее масштабирование системы^[28].

Хотя REST оставался доминирующим архитектурным стилем, продолжился рост популярности альтернативных технологий. GraphQL, разработанный Facebook, позволил клиентам запрашивать только необходимые данные, решая проблему избыточной или недостаточной выборки, что сделало его особенно востребованным для мобильных и фронтенд-приложений^[29][30]. В то же время gRPC, созданный Google, получил распространение для взаимодействия между микросервисами благодаря высокой производительности, использованию протокола HTTP/2 и бинарного формата данных Protocol Buffers^[31].

Укрепилась тенденция рассматривать API как полноценный продукт (API-as-a-Product), у которого есть свой жизненный цикл, целевая аудитория (разработчики) и бизнес-цели^[32]. Одновременно с ростом числа API и передаваемых через них конфиденциальных данных критически важным аспектом стала безопасность^[33]. Громкие инциденты, связанные с уязвимостями, подчеркнули необходимость проактивного подхода к защите, а список OWASP API Security Top 10 стал ключевым ориентиром для разработчиков^[34][33].

API стали ключевым инструментом для построения цифровых экосистем, позволяя компаниям интегрироваться с партнерами и предоставлять свои сервисы на сторонних платформах^[35]. Особенно заметной эта тенденция была в финансовом секторе (финтех), где открытые API стали основой для развития открытого банкинга^[36].

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

Один API может реализоваться в нескольких независимых библиотеках.

Изоляция API от реализации позволяет программам на одном языке использовать библиотеки, написанные на другом. Например, компилируемые в байткод Scala и Java дают возможность разработчикам Scala использовать любые API Java^[37].

Вид и структура API зависит от парадигмы: для процедурных языков вроде Lua — это набор процедур для выполнения кода, управления ошибками; для ООП, например, Java — набор классов и методов^[38][39]. Закон Хайрума гласит: «Достаточно большого количества пользователей API, чтобы начать использовать любые наблюдаемые особенности вашей системы — независимо от ваших намерений»^[40]. Исследования доказывают: большинство программ используют лишь незначительную часть предоставляемого API^[41].

Биндинг языка тоже является API: сопоставляя элементы одного языка с интерфейсом на другом, возможно использовать код сторонних сервисов на разных языках^[42]. Инструменты вроде SWIG или F2PY позволяют создавать такие интерфейсы^[43].

API может быть частью программного фреймворка: фреймворк часто объединяет несколько библиотек, реализующих несколько API, а управление программным потоком зачастую реализовано через инверсию управления или аналогичные механизмы^[44][45].

API может определять интерфейс между приложением и операционной системой^[46]. Например, спецификация POSIX включает стандартный набор API, позволяющий портировать приложения между совместимыми ОС.

Linux и BSD — примеры ОС, реализующих POSIX API^[47].

Microsoft поддерживает обратную совместимость своих API, особенно Windows API (Win32), чтобы старые приложения продолжали работать на новых версиях Windows посредством режима совместимости^[48]. Однако преимуществом для разработчиков является доступ к внутренним API операционной системы^[49][50].

API отличается от двоичного интерфейса приложения (ABI): API описывает структуру исходного кода, а ABI — бинарный уровень. POSIX — пример API, в то время как Linux Standard Base — ABI^[51][52].

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

Например, Java Database Connectivity (JDBC) позволяет запрашивать разные базы данных с помощью единого интерфейса, а Java RMI (remote method invocation) реализует удалённые вызовы методов по собственному протоколу^[53][54].

Таким образом, удалённые API поддерживают объектную абстракцию в ООП: вызов метода-прокси на локальном объекте приводит к вызову на удалённом объекте и получению результата.

Изменения в объекте-прокси отражаются и на удалённом объекте^[55].

Web API — определённые интерфейсы для взаимодействия между предприятиями и приложениями, использующими их ресурсы. Такой подход строится на представлении набора сервисов посредством программного интерфейса^[56].

Обычно Web API определяется спецификациями HTTP-запросов и структурой ответов в формате XML или JSON. Пример — API службы доставки, интегрируемое с сайтом интернет-магазина для автоматизации оформления заказов: программное обращение к API позволяет получить актуальные тарифы без ручного обновления базы сайта. Исторически Web API отождествлялись с веб-сервисами, но с развитием Web 2.0 произошёл сдвиг в сторону архитектуры REST и ресурсно-ориентированных интерфейсов^[57]. В контексте семантической паутины Web API могут представлять интерфейсы для инженерии онтологий. С помощью Web API могут комбинироваться разные сервисы в новых приложениях (mashup)^[58].

В области социальных сетей Web API позволяют обмениваться данными и контентом между разными платформами^[59]. Пример: REST API Twitter позволяет получать и публиковать данные о трендах и других событиях на платформе^[60].

Дизайн API существенно влияет на его пригодность и удобство. Принцип инкапсуляции означает, что программный интерфейс скрывает внутреннюю реализацию модулей, облегчая модульное проектирование^[61]. Проектирование API является важной частью архитектуры программного обеспечения^[62].

В 2020-х годах одним из ключевых подходов к проектированию стал «API-first» (букв. «сначала API»). Эта методология предполагает, что разработка API предшествует созданию клиентских приложений, которые будут его использовать^[63]. Такой подход обеспечивает лучшую масштабируемость, готовность к интеграциям и упрощает повторное использование функций API для различных продуктов^[63]. Становление «API-first» как стандарта является эволюционным процессом: получив широкое распространение к 2020 году, к 2025 году он начал рассматриваться как общепринятый отраслевой стандарт^[64][65][66].

API являются одним из распространённых способов интеграции между компаниями, предоставляющими технологии. Поставщики и потребители API образуют деловые экосистемы^[67].

Существуют следующие основные модели распространения API^[68]:

• Приватные — доступны только для внутреннего использования организации.
• Партнёрские — предоставляются только избранным бизнес-партнёрам (например, сервисы вызова такси предоставляют отдельный API для интеграции c приложениями партнёров^[69]).
• Публичные — открыты для широкой аудитории (например, Windows API от Microsoft, Cocoa от Apple). Однако не все такие API доступны всем без ограничений: например, Cloudflare или Voxility предоставляют API только своим клиентам или аффилированным лицам и требуют использования токена для авторизации^[70][71].

API как продукт (англ. API-as-a-Product, AaaP) — это подход, при котором API рассматривается не как технический компонент, а как полноценный бизнес-продукт^[65]. Такая концепция предполагает, что у API есть чёткая бизнес-ценность, стратегия развития, собственный жизненный цикл и целевая аудитория (разработчики)^[72].

Идея начала формироваться в конце 2000-х годов с появлением компаний, для которых API стал основным продуктом, например, Twilio (2007) и Stripe. К концу 2010-х годов концепция была чётко сформулирована: появились публикации, описывающие необходимость управлять API так же, как и любым другим продуктом, включая создание документации, порталов для разработчиков, моделей монетизации и обеспечение поддержки^[73][74].

В 2020-х годах подход стал мейнстримом, а к 2022 году превратился в одну из главных тенденций в отрасли^[65]. Компании начали рассматривать API как критически важные бизнес-активы, способные генерировать прямой доход и расширять присутствие на рынке^[72]. Монетизация API стала распространённой практикой^[75]. Например, в 2022 году в финансовом секторе наблюдался 16%-ный рост монетизации API, что подтвердило сдвиг в восприятии интерфейсов от технических инструментов к коммерческим продуктам^[76]. Ускоренная цифровая трансформация, вызванная пандемией COVID-19, также подчеркнула стратегическую важность API для бизнеса^[77].

Ключевым фактором успеха API как продукта стал опыт разработчика (англ. Developer Experience, DX). Качественная документация, простота использования и поддержка стали неотъемлемой частью предложения^[72].

Концепция открытых API (англ. Open API) стала одним из ключевых направлений развития в 2023 году. API всё чаще используются для построения цифровых экосистем, позволяя компаниям интегрироваться с партнёрами и предоставлять свои сервисы на сторонних платформах. Этот подход тесно связан с концепцией «API как продукт», в рамках которой компании монетизируют свои API, предлагая их внешним разработчикам для создания новых бизнес-моделей^[78].

Наиболее ярко эта тенденция проявилась в финансовом секторе (финтех) с активным внедрением открытого банкинга. Например, в России в 2023 году на площадке Ассоциации Финтех был создан Экспертный совет по внедрению Открытых API, а также разработаны стандарты и дорожная карта их развития, что способствует созданию новых финансовых сервисов и интеграций^[79].

Внедрение стандартов открытого банкинга (Open Banking) в России представляет собой многоэтапный процесс, координируемый Банком России совместно с Ассоциацией ФинТех (АФТ). В октябре 2020 года были опубликованы первые стандарты открытых банковских интерфейсов, носившие рекомендательный характер^[80]. В 2021 году прошли первые пилотные проекты, в рамках которых отрабатывался обмен публичной информацией (например, о расположении банкоматов) и тестировались первые стандарты^[81][82].

Важным шагом стала публикация в ноябре 2022 года «Концепции внедрения Открытых API на финансовом рынке», в которой были изложены подходы и этапы дальнейшего развития технологии^[83]. С 2023 года началась публикация новых стандартов^[84]. В 2024 году были запущены более масштабные пилотные проекты для тестирования конкретных бизнес-кейсов, таких как корпоративный мультибанкинг и цифровое урегулирование ДТП^[81]. По состоянию на сентябрь 2024 года в одном из таких пилотов участвовало 18 организаций, включая банки, страховые и нефинансовые компании^[85]. В декабре 2024 года ЦБ опубликовал обновлённые стандарты безопасности, ориентированные на российскую криптографию, которые вступили в силу с 1 января 2025 года в качестве рекомендации^[86].

На середину 2025 года запланирован запуск прототипа среды Открытых API^[87]. В течение года также будет проводиться пилотирование Платформы коммерческих согласий — единого окна для управления согласиями граждан на передачу данных^[81]. Изначально предполагалось, что обязательное применение стандартов для крупнейших участников рынка начнётся с 2026 года^[88], однако впоследствии сроки были перенесены на период после 2026 года и будут определены после принятия соответствующего федерального закона^[89].

Ключевое требование к публичным API — это стабильность интерфейса. Любые частые или неожиданные изменения (например, добавление новых параметров) могут нарушить работоспособность клиентских программ^[90].

Если часть API нестабильна, это должно быть явно указано в документации. Например, в Google Guava нестабильные части помечены аннотацией @Beta^[91].

Публичный API может объявлять определённые части устаревшими (deprecated) или отменёнными. Это позволяет постепенно вывести из эксплуатации устаревающие функции без резких изменений для клиентов^[92].

Клиентский код иногда создаёт нестандартные применения API, которые не были задуманы его проектировщиками^[93]. С февраля 2017 по ноябрь 2019, по данным Akamai, было зафиксировано более 85 млрд атак на публичные платформы API, из них 16,5 млрд — на финансовый сектор^[94].

В 2020-х годах, с ростом числа и сложности API, обеспечение их безопасности стало первоочередной задачей^[95]. Современные угрозы требуют продвинутых средств защиты, использующих искусственный интеллект и машинное обучение для выявления уязвимостей и аномального трафика в реальном времени^[95]. Для защиты API применяются надёжные методы аутентификации и авторизации, такие как OAuth и JWT^[96]. Помимо защиты, генеративный ИИ и другие его виды также используются для автоматизации жизненного цикла API, включая генерацию документации и мониторинг использования, что способствует поддержанию их стабильности и качества^[97][98].

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

Документация критически важна для разработки и поддержки приложений, использующих API^[99]. Традиционно она оформляется как справочные файлы или страницы, но может размещаться и на форумах, блогах и специализировнных сервисах^[100].

Современные инструменты автогенерации (например, Javadoc, Pydoc) обеспечивают единообразие технической и описательной части. Обычно документацию API дополняют описанием классов и методов, примерами использования, соображениями о производительности и ограничениями. Реализация внутренней логики редко раскрывается^[101].

Документация также указывает на ограничения API: например, функция не принимает аргументы null, не является потокобезопасной и т.д^[102]. Из-за объёма актуальность документации становится сложной задачей.

Документацию можно обогащать метаданными, например, аннотациями Java^[103]. Автоматизированные инструменты могут генерировать документацию на основе анализа многих программ-клиентов^[104].

С ростом конкуренции на рынке API одним из решающих факторов успеха стал опыт разработчика (англ. Developer Experience, DX). Компании начали уделять повышенное внимание качеству документации, простоте использования и поддержке для привлечения и удержания пользователей своих API^[105].

В 2010 году Oracle подала судебный иск против Google за использование API Java в системе Android без лицензии, хотя аналогичное разрешение ранее получил проект OpenJDK. Судья Уильям Алсап постановил, что API не подлежит авторскому праву в США, иначе можно было бы монополизировать системные команды посредством авторских символов^[106][107].

Постановление было отменено апелляционным судом в 2014 году, вопрос о добросовестном использовании остался неурегулированным^[108][109].

В 2016 году жюри признало реализацию API добросовестным использованием, но Oracle продолжила бороться в апелляции. Апелляционный суд признал позицию Oracle, а Google обжаловала решение в Верховный суд США, который рассмотрел обе жалобы^[110]. Из-за пандемии COVID-19 слушания были перенесены на октябрь 2020 года^[111].

Верховный суд США в итоге принял сторону Google^[112].

• ASPI — новый стандарт интерфейса для устройств SCSI
• Cocoa и Carbon — для Macintosh
• DirectX — для Microsoft Windows
• EHLLAPI
• Java API
• ODBC — для Microsoft Windows
• OpenAL — кроссплатформенный звуковой API
• OpenCL — кроссплатформенный API для вычислений на CPU и GPU
• OpenGL — кроссплатформенный графический API
• OpenMP — API для программирования многопроцессорных систем с общей памятью на C, C++ и Fortran
• SAPI — серверный API приложений
• SDL