АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

API

API (англ. application programming interface, интерфейс программирования приложений) — это способ взаимодействия между компьютерами или отдельными программами. API представляет собой разновидность программного интерфейса, предлагающего определённые сервисы другим программным компонентам[1]. Документ или стандарт, описывающий процесс создания такого интерфейса, называют спецификацией API. Компьютерная система, реализующая этот стандарт, называется реализующей или предоставляющей API. Термин «API» может означать как спецификацию, так и её реализацию.

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

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

В современной практике под API часто подразумевают Web API[2], позволяющие компьютерам взаимодействовать друг с другом через интернет. Также существуют API для языков программирования, программных библиотек, операционных систем и даже аппаратных средств. Концепция API возникла ещё в 1940-х годах, но сам термин стал широко использоваться с 1960-70-х годов.

Назначение

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

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

undefined

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

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

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

История термина

undefined

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

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

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

undefined

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

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

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

undefined

С развитием удалённых вызовов процедур и 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 и становление API-экономики

В начале 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 как стратегический актив

В начале 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 может реализоваться в нескольких независимых библиотеках.

Изоляция 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

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

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

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

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

Web API

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 являются одним из распространённых способов интеграции между компаниями, предоставляющими технологии. Поставщики и потребители API образуют деловые экосистемы[67].

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

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

API как продукт

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 и экосистемы

Концепция открытых 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

Ключевое требование к публичным 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

См. также

Примечания

  1. ↑ 1 2 Reddy, Martin. API Design for C++. — Elsevier Science, 2011. — P. 1. — ISBN 9780123850041.
  2. ↑ 1 2 Lane, Kin Intro to APIs: History of APIs. Postman (10 октября 2019). Дата обращения: 18 сентября 2020. Архивировано 9 сентября 2025 года.
  3. ↑ 1 2 Pedro, Bruno. Building an API Product: Design, Implement, Release, and Maintain API Products that Meet User Needs. — Packt Publishing, 2024. — P. 4. — ISBN 9781837638536.
  4. ↑ Biehl, Matthias. RESTful API Design. — API-University Press, 2016. — P. 10. — ISBN 9781514735169.
  5. ↑ Clarke, Steven Measuring API Usability. Dr. Dobb's (2004). Дата обращения: 29 июля 2016. Архивировано 25 июля 2012 года.
  6. ↑ Jin, Brenda. Preface // Designing Web APIs: Building APIs That Developers Love / Brenda Jin, Saurabh Sahni, Amir Shevat. — O'Reilly Media, 2018. — ISBN 9781492026877.
  7. ↑ Geewax, JJ. API Design Patterns. — Manning, 2021. — P. 6. — ISBN 9781638350330.
  8. ↑ Jacobson, Daniel. APIs: A Strategy Guide / Daniel Jacobson, Greg Brail, Dan Woods. — O'Reilly Media, 2011. — P. 4. — ISBN 9781449321642.
  9. ↑ 1 2 Database architectures – a feasibility workshop, Washington, DC: U.S. Department of Commerce, National Bureau of Standards, апрель 1981, pp. 45–47, NBS special publication 500-76, <https://hdl.handle.net/2027/mdp.39015077587742?urlappend=%3Bseq=53>. Проверено 18 сентября 2020.. 
  10. ↑ 1 2 3 4 Bloch, Joshua (8 августа 2018). A Brief, Opinionated History of the API (Speech). QCon. San Francisco: InfoQ. Дата обращения 18 сентября 2020.
  11. ↑ 1 2 Cotton, Ira W.; Greatorex, Frank S. (декабрь 1968). “Data structures and techniques for remote computer graphics”. Proceedings of the December 9–11, 1968, Fall Joint Computer Conference. AFIPS 1968 Fall Joint Computer Conference. I. San Francisco, California: Association for Computing Machinery. pp. 533—544. DOI:10.1145/1476589.1476661. ISBN 978-1450378994. OCLC 1175621908. Проверьте дату в |date= (справка на английском)
  12. ↑ Date, C. J. E. F. Codd and Relational Theory: A Detailed Review and Analysis of Codd's Major Database Writings. — Lulu.com, 2019. — P. 135. — ISBN 978-1684705276.
  13. ↑ Date, C. J.; Codd, E. F. (январь 1975). “The relational and network approaches: Comparison of the application programming interfaces”. In Randall Rustin. Proceedings of 1974 ACM-SIGMOD Workshop on Data Description, Access and Control. SIGMOD Workshop 1974. 2. Ann Arbor, Michigan: Association for Computing Machinery. pp. 83—113. DOI:10.1145/800297.811532. ISBN 978-1450374187. OCLC 1175623233. Проверьте дату в |date= (справка на английском)
  14. ↑ Carl, Malamud. Analyzing Novell Networks. — Van Nostrand Reinhold, 1990. — P. 294. — ISBN 978-0442003647.
  15. ↑ Fielding, Roy (2000). Architectural Styles and the Design of Network-based Software Architectures (PhD). Дата обращения 18 сентября 2020.
  16. ↑ Dotsika, Fefie (август 2010). “Semantic APIs: Scaling up towards the Semantic Web”. International Journal of Information Management. 30 (4): 335—342. DOI:10.1016/j.ijinfomgt.2009.12.003. Проверьте дату в |date= (справка на английском)
  17. ↑ Jin, Brenda. Designing Web APIs / Brenda Jin, Saurabh Sahni, Amir Shevat. — O'Reilly Media, 2018. — ISBN 9781492026877.
  18. ↑ 1 2 The History of REST APIs. readme.com. Дата обращения: 3 ноября 2025. Архивировано 24 сентября 2025 года.
  19. ↑ 1 2 The Evolution of APIs: From the Pre-REST Era to Modern RESTful and Beyond. Strapi. Дата обращения: 3 ноября 2025. Архивировано 12 сентября 2025 года.
  20. ↑ GraphQL на клиенте: история появления и сравнение с REST. Habr (15 августа 2022). Дата обращения: 3 ноября 2025.
  21. ↑ Что такое GraphQL, как он работает и зачем понадобился. Skillbox.ru. Дата обращения: 3 ноября 2025. Архивировано 9 октября 2025 года.
  22. ↑ 1 2 GraphQL: что это, как работает, преимущества и недостатки. Ylab. Дата обращения: 3 ноября 2025. Архивировано 7 августа 2025 года.
  23. ↑ GraphQL and how did it evolve from REST API? MuleSoft. Дата обращения: 3 ноября 2025. Архивировано 8 июля 2025 года.
  24. ↑ A Brief History of GraphQL. DEV Community. Дата обращения: 3 ноября 2025. Архивировано 20 сентября 2025 года.
  25. ↑ 1 2 Развитие экосистем - основной тренд трансформации банковского бизнеса. CyberLeninka. Дата обращения: 3 ноября 2025.
  26. ↑ 1 2 API-First разработка: что это и почему становится стандартом. itproger.com. Дата обращения: 3 ноября 2025.
  27. ↑ API-first: как это работает и зачем нужно. Habr (21 сентября 2022). Дата обращения: 3 ноября 2025.
  28. ↑ API-First подход в разработке: как это ускоряет интеграции и расширяет возможности вашего проекта. Meta-sistem.md. Дата обращения: 3 ноября 2025.
  29. ↑ 5 тенденций в области API, которых стоит ожидать в 2023 году. Astera. Дата обращения: 3 ноября 2025.
  30. ↑ REST, GraphQL и gRPC: гайд для начинающих разработчиков. proglib.io (3 июля 2024). Дата обращения: 3 ноября 2025. Архивировано 8 августа 2025 года.
  31. ↑ REST, gRPC, GraphQL: что это такое и в чем разница. Habr (26 сентября 2024). Дата обращения: 3 ноября 2025.
  32. ↑ API как продукт. Habr (9 февраля 2023). Дата обращения: 3 ноября 2025.
  33. ↑ 1 2 Топ-10 угроз безопасности API 2019 по версии OWASP. Habr (25 мая 2020). Дата обращения: 3 ноября 2025.
  34. ↑ Безопасность API. DST Global. Дата обращения: 3 ноября 2025. Архивировано 18 июля 2025 года.
  35. ↑ Disruptive API trends for 2020. Axway Blog. Дата обращения: 3 ноября 2025. Архивировано 20 мая 2025 года.
  36. ↑ Открытые API как ведущий тренд развития финтеха. IT World (28 ноября 2022). Дата обращения: 3 ноября 2025. Архивировано 21 марта 2025 года.
  37. ↑ Odersky, Martin; Spoon, Lex; Venners, Bill Combining Scala and Java. artima.com (10 декабря 2008). Дата обращения: 29 июля 2016. Архивировано 16 сентября 2025 года.
  38. ↑ de Figueiredo, Luiz Henrique; Ierusalimschy, Roberto; Filho, Waldemar Celes (1994). “The design and implementation of a language for extending applications”. Proceedings of XXI Brazilian Seminar on Software and Hardware. pp. 273—284. CiteSeerX 10.1.1.47.5194. S2CID 59833827. Дата обращения 29 июля 2016.
  39. ↑ Sintes, Tony Just what is the Java API anyway? JavaWorld (13 июля 2001). Дата обращения: 18 июля 2020. Архивировано 26 июля 2020 года.
  40. ↑ Software engineering at Google: lessons learned from programming over time. — Sebastopol, CA : O'Reilly Media, 2020. — ISBN 9781492082798.
  41. ↑ Mastrangelo, Luis; Ponzanelli, Luca; Mocci, Andrea; Lanza, Michele; Hauswirth, Matthias; Nystrom, Nathaniel (23 октября 2015). “Use at your own risk: the Java unsafe API in the wild”. Proceedings of the 2015 ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications. New York, New York, U.S.: Association for Computing Machinery. pp. 695—710. DOI:10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  42. ↑ Emery, David Standards, APIs, Interfaces and Bindings. Acm.org. Дата обращения: 8 августа 2016. Архивировано 16 января 2015 года.
  43. ↑ F2PY.org. F2PY.org. Дата обращения: 18 декабря 2011.
  44. ↑ Fowler, Martin Inversion Of Control. Архивировано 28 июня 2005 года.
  45. ↑ Fayad, Mohamed Object-Oriented Application Frameworks. Архивировано 5 октября 2025 года.
  46. ↑ Lewine, Donald A. POSIX Programmer's Guide. — O'Reilly & Associates, Inc., 1991. — P. 1. — ISBN 9780937175736.
  47. ↑ West, Joel; Dedrick, Jason (2001). “Open source standardization: the rise of Linux in the network era” (PDF). Knowledge, Technology & Policy. 14 (2): 88—112. DOI:10.1007/PL00022278. Дата обращения 2 августа 2016.
  48. ↑ Microsoft. Support for Windows XP 4. Microsoft (октябрь 2001). Архивировано 26 сентября 2009 года.
  49. ↑ Barney, Douglas (2 ноября 1987). “Balancing on the high wire of Microsoft's success”. Computerworld. XXI (44): SR15. Дата обращения 8 июня 2025.
  50. ↑ Gates, Bill; Manzi, Jim & Esber, Ed (2 ноября 1987). Интервью c Paul Gillin, The great software debate, Computerworld Т. XXI (44): SR7, <https://books.google.com/books?id=mUSIMiurpfYC&pg=PP73>. Проверено 8 июня 2025.. 
  51. ↑ LSB Introduction. Linux Foundation (21 июня 2012). Дата обращения: 27 марта 2015. Архивировано 2 апреля 2015 года.
  52. ↑ Stoughton, Nick Update on Standards. USENIX (апрель 2005). Дата обращения: 4 июня 2009. Архивировано 7 октября 2006 года.
  53. ↑ Bierhoff, Kevin (23 апреля 2009). “API Protocol Compliance in Object-Oriented Software” (PDF). CMU Institute for Software Research. Дата обращения 29 июля 2016.
  54. ↑ Wilson, M. Jeff Get smart with proxies and RMI. JavaWorld (10 ноября 2000). Дата обращения: 18 июля 2020. Архивировано 20 июля 2020 года.
  55. ↑ Henning, Michi. Advanced CORBA Programming with C++ / Michi Henning, Steve Vinoski. — Addison-Wesley, 1999. — ISBN 978-0201379273.
  56. ↑ API-fication. www.hcltech.com (август 2014). Архивировано 5 октября 2025 года.
  57. ↑ Benslimane, Djamal; Schahram Dustdar; Amit Sheth (2008). “Services Mashups: The New Generation of Web Applications”. IEEE Internet Computing. IEEE. 12 (5): 13—15. DOI:10.1109/MIC.2008.110. Дата обращения 1 октября 2019.
  58. ↑ Niccolai, James So What Is an Enterprise Mashup, Anyway? PC World (23 апреля 2008). Дата обращения: 17 сентября 2017. Архивировано 10 октября 2017 года.
  59. ↑ Parr, Ben The Evolution of the Social Media API. Mashable (21 мая 2009). Дата обращения: 26 июля 2016. Архивировано 23 мая 2009 года.
  60. ↑ GET trends/place (англ.). developer.twitter.com. Дата обращения: 30 апреля 2020. Архивировано 13 ноября 2017 года.
  61. ↑ Parnas, D.L. (1972). “On the Criteria To Be Used in Decomposing Systems into Modules” (PDF). Communications of the ACM. 15 (12): 1053—1058. DOI:10.1145/361598.361623. S2CID 53856438.
  62. ↑ Garlan, David; Shaw, Mary (январь 1994). “An Introduction to Software Architecture” (PDF). Advances in Software Engineering and Knowledge Engineering. 1. Дата обращения 8 августа 2016. Проверьте дату в |date= (справка на английском)
  63. ↑ 1 2 API-тренды 2025: Как интеграционные технологии меняют бизнес-ландшафт. TAdviser. Дата обращения: 3 ноября 2025. Архивировано 10 августа 2025 года.
  64. ↑ 2025 Top 8 API Management Trends. api7.ai. Дата обращения: 3 ноября 2025. Архивировано 31 августа 2025 года.
  65. ↑ 1 2 3 API-тренды 2023: от безопасности до AI. Habr (13 марта 2023). Дата обращения: 3 ноября 2025.
  66. ↑ API-First Strategy Becomes Standard Practice in 2025: An Industries Overview. Techloy. Дата обращения: 3 ноября 2025. Архивировано 15 июля 2025 года.
  67. ↑ de Ternay, Guerric Business Ecosystem: Creating an Economic Moat. BoostCompanies (10 октября 2015). Дата обращения: 1 февраля 2016. Архивировано 17 сентября 2016 года.
  68. ↑ Boyd, Mark Private, Partner or Public: Which API Strategy Is Best for Business? ProgrammableWeb (21 февраля 2014). Дата обращения: 2 августа 2016. Архивировано 8 мая 2014 года.
  69. ↑ Weissbrot, Alison Car Service APIs Are Everywhere, But What's In It For Partner Apps? AdExchanger (7 июля 2016). Архивировано 7 сентября 2025 года.
  70. ↑ Cloudflare API v4 Documentation. cloudflare (25 февраля 2020). Дата обращения: 27 февраля 2020.
  71. ↑ Liew, Zell Car Service APIs Are Everywhere, But What's In It For Partner Apps. Smashing Magazine (17 января 2018). Дата обращения: 27 февраля 2020. Архивировано 14 июня 2025 года.
  72. ↑ 1 2 3 10 Trends Shaping the API Industry in 2022. Stoplight Blog. Дата обращения: 3 ноября 2025. Архивировано 23 июля 2024 года.
  73. ↑ The stages of the API product lifecycle. MuleSoft Blog. Дата обращения: 3 ноября 2025. Архивировано 8 августа 2025 года.
  74. ↑ API as a Product. stoplight.io. Дата обращения: 3 ноября 2025. Архивировано 14 июня 2025 года.
  75. ↑ The API Ecosystem. Sysarcinfomatix. Дата обращения: 3 ноября 2025.
  76. ↑ 2022 State of APIs: What Developers are Saying. RapidAPI. Дата обращения: 3 ноября 2025. Архивировано 5 апреля 2023 года.
  77. ↑ Announcing the 2020 State of the API Report. Postman Blog. Дата обращения: 3 ноября 2025. Архивировано 6 сентября 2025 года.
  78. ↑ 11 API trends for 2023 and beyond. Gravitee.io. Дата обращения: 3 ноября 2025. Архивировано 11 февраля 2025 года.
  79. ↑ Мировой атлас открытого банкинга: как развиваются открытые API в России и в мире. rtln.ru. Дата обращения: 3 ноября 2025.
  80. ↑ Банк России публикует стандарты Открытых API. Банк России (1 октября 2020). Дата обращения: 3 ноября 2025. Архивировано 24 апреля 2025 года.
  81. ↑ 1 2 3 Основные направления развития финансового рынка Российской Федерации на 2025 год и период 2026 и 2027 годов. Банк России (2 сентября 2024). Дата обращения: 3 ноября 2025. Архивировано 19 сентября 2025 года.
  82. ↑ Ассоциация «Финтех» провела первые пилотные проекты по применению стандартов Open API. Habr (13 декабря 2021). Дата обращения: 3 ноября 2025.
  83. ↑ Банк России разработал Концепцию внедрения открытых API на финансовом рынке. Гарант (18 ноября 2022). Дата обращения: 3 ноября 2025.
  84. ↑ ЦБ РФ с 2023г начнет публиковать стандарты открытых API, до 2024г они будут рекомендательными. Финмаркет (17 ноября 2022). Дата обращения: 3 ноября 2025. Архивировано 4 октября 2023 года.
  85. ↑ ЦБ в 2025 году планирует пилотировать платформу коммерческих согласий. Интерфакс (27 сентября 2024). Дата обращения: 3 ноября 2025. Архивировано 14 июня 2025 года.
  86. ↑ Центробанк опубликовал обновленные стандарты безопасности открытых API. ComNews.ru (16 декабря 2024). Дата обращения: 3 ноября 2025. Архивировано 18 января 2025 года.
  87. ↑ К середине 2025 года в России появится прототип Open API. id-sys.ru (27 сентября 2024). Дата обращения: 3 ноября 2025. Архивировано 15 августа 2025 года.
  88. ↑ Открытые API. Ассоциация ФинТех. Дата обращения: 3 ноября 2025.
  89. ↑ Open Bank System (Открытая банковская платформа). TAdviser. Дата обращения: 3 ноября 2025.
  90. ↑ Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). An Empirical Study on Evolution of API Documentation. International Conference on Fundamental Approaches to Software Engineering. Lecture Notes in Computer Science. 6603. pp. 416—431. DOI:10.1007/978-3-642-19811-3_29. ISBN 978-3-642-19810-6. Дата обращения 22 июля 2016.
  91. ↑ Google Core Libraries for Java Проект API на сайте GitHub
  92. ↑ Oracle How and When to Deprecate APIs. Java SE Documentation. Дата обращения: 2 августа 2016. Архивировано 4 декабря 2011 года.
  93. ↑ Mendez, Diego; Baudry, Benoit; Monperrus, Martin (2013). Empirical evidence of large-scale diversity in API usage of object-oriented software. 2013 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM). pp. 43—52. arXiv:1307.4062. DOI:10.1109/SCAM.2013.6648183. ISBN 978-1-4673-5739-5. S2CID 6890739.
  94. ↑ Takanashi, Dean Akamai: Cybercriminals are attacking APIs at financial services firms. Venture Beat (19 февраля 2020). Дата обращения: 27 февраля 2020. Архивировано 20 февраля 2020 года.
  95. ↑ 1 2 API в 2024 году: безопасность, монетизация и искусственный интеллект. itWeek (18 марта 2024). Дата обращения: 3 ноября 2025.
  96. ↑ 5 API trends we’re seeing in 2024. Visma. Дата обращения: 3 ноября 2025. Архивировано 21 июня 2025 года.
  97. ↑ 11 API Trends to Watch For in 2024 and Beyond. DreamFactory Blog. Дата обращения: 3 ноября 2025. Архивировано 12 мая 2025 года.
  98. ↑ State of the API 2024: влияние генеративного ИИ продолжает расширяться. itWeek (12 сентября 2024). Дата обращения: 3 ноября 2025. Архивировано 16 ноября 2024 года.
  99. ↑ Dekel, Uri; Herbsleb, James D. (май 2009). “Improving API Documentation Usability with Knowledge Pushing”. Institute for Software Research, School of Computer Science. CiteSeerX 10.1.1.446.4214. Проверьте дату в |date= (справка на английском)
  100. ↑ Parnin, Chris; Treude, Cristoph (май 2011). “Measuring API documentation on the web”. Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering. pp. 25—30. DOI:10.1145/1984701.1984706. ISBN 9781450305952. S2CID 17751901. Дата обращения 22 июля 2016. Проверьте дату в |date= (справка на английском)
  101. ↑ Maalej, Waleed; Robillard, Martin P. (сентябрь 2012). “Patterns of Knowledge in API Reference Documentation” (PDF). IEEE Transactions on Software Engineering. 39 (9): 1264—1282. DOI:10.1109/TSE.2013.12. Дата обращения 22 июля 2016. Проверьте дату в |date= (справка на английском)
  102. ↑ Monperrus, Martin; Eichberg, Michael; Tekes, Elif; Mezini, Mira (3 декабря 2011). “What should developers be aware of? An empirical study on the directives of API documentation”. Empirical Software Engineering. 17 (6): 703—737. arXiv:1205.6363. DOI:10.1007/s10664-011-9186-4. S2CID 8174618.
  103. ↑ Annotations. Sun Microsystems. Дата обращения: 30 сентября 2011. Архивировано 25 сентября 2011 года.
  104. ↑ Bruch, Marcel; Mezini, Mira; Monperrus, Martin (2010). Mining subclassing directives to improve framework reuse. 2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010). pp. 141—150. CiteSeerX 10.1.1.434.15. DOI:10.1109/msr.2010.5463347. ISBN 978-1-4244-6802-7. S2CID 1026918.
  105. ↑ Top 10 API trends for 2021. Axway Blog. Дата обращения: 3 ноября 2025. Архивировано 13 августа 2025 года.
  106. ↑ APIs Can't be Copyrighted Says Judge in Oracle Case. TGDaily (1 июня 2012). Дата обращения: 6 декабря 2012. Архивировано 16 сентября 2025 года.
  107. ↑ Oracle America, Inc. vs. Google Inc. Wired (31 мая 2012). Дата обращения: 22 сентября 2013. Архивировано 10 июня 2012 года.
  108. ↑ Oracle Am., Inc. v. Google Inc., No. 13-1021, Fed. Cir. 2014. Архивировано 10 октября 2014 года.
  109. ↑ Rosenblatt, Seth. Court sides with Oracle over Android in Java patent appeal, CNET (9 мая 2014). Архивировано 10 мая 2014 года. Дата обращения: 10 мая 2014.
  110. ↑ Lee, Timothy Google asks Supreme Court to overrule disastrous ruling on API copyrights. Ars Technica (25 января 2019). Дата обращения: 8 февраля 2019. Архивировано 25 января 2019 года.
  111. ↑ vkimber Google LLC v. Oracle America, Inc. (англ.). LII / Legal Information Institute (28 сентября 2020). Дата обращения: 6 марта 2021. Архивировано 5 октября 2025 года.
  112. ↑ Supreme Court of the United States, No. 18–956, GOOGLE LLC, PETITIONER v. ORACLE AMERICA, INC. (5 апреля 2021). Архивировано 11 октября 2025 года.

Литература

Ссылки

Категории