Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Для использования в других целях, см API (значения) .
"Api.php" перенаправляется сюда. Информацию об API Википедии см. В разделе Special: ApiHelp .

Интерфейс прикладного программирования ( API ) представляет собой вычислительное интерфейс , который определяет взаимодействия между несколькими промежуточными программным обеспечением. Он определяет типы вызовов или запросов, которые могут быть сделаны, как их делать, форматы данных, которые следует использовать, соглашения, которым нужно следовать, и т. Д. Он также может предоставлять механизмы расширения, чтобы пользователи могли расширять существующие функциональные возможности различными способами и в разной степени. [1] API может быть полностью настраиваемым, специфичным для компонента или разработанным на основе отраслевого стандарта для обеспечения взаимодействия. Благодаря сокрытию информации API-интерфейсы обеспечивают модульное программирование , позволяя пользователям использовать интерфейс независимо от реализации.

Цель [ править ]

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

История термина [ править ]

Диаграмма 1978 года, предлагающая расширить идею API, чтобы он стал общим программным интерфейсом, помимо прикладных программ . [3]

Значение термина API расширилось за свою историю. Сначала он описывал интерфейс только для программ, предназначенных для конечного пользователя, известных как прикладные программы . Это происхождение до сих пор отражено в названии «интерфейс прикладного программирования». Сегодня термин API шире, включая также служебное программное обеспечение и даже аппаратные интерфейсы. [4]

Идея API намного старше термина. Британские ученые-компьютерщики Уилкс и Уиллер в 1940-х годах работали над модульными библиотеками программного обеспечения для компьютера EDSAC . Джошуа Блох утверждает, что Уилкс и Уиллер «скрыто изобрели» API, потому что это скорее открытая концепция, чем изобретенная. [4]

Хотя люди, придумавшие термин API, реализовывали программное обеспечение на Univac 1108 , целью их API было сделать возможными программы, независимые от оборудования . [5]

Термин «интерфейс прикладной программы» (без суффикса -ing ) впервые был записан в статье под названием Структуры данных и методы удаленной компьютерной графики, представленной на конференции AFIPS в 1968 году. [6] [4] Авторы этой статьи используют термин для описания взаимодействия приложения - в данном случае графической программы - с остальной частью компьютерной системы. Согласованный интерфейс приложения (состоящий из вызовов подпрограмм Fortran ) был предназначен для того, чтобы освободить программиста от работы с особенностями устройства графического отображения и обеспечить независимость от оборудования в случае замены компьютера или дисплея. [5]

Термин был введен в области баз данных по CJ Date [7] в работе 1974 г. под названием реляционной и сети Подходы: Сравнение Application Programming Interface . [8] API стал частью структуры ANSI / SPARC для систем управления базами данных . Эта структура обрабатывала интерфейс прикладного программирования отдельно от других интерфейсов, таких как интерфейс запросов. Специалисты по базам данных в 1970-х годах заметили, что эти разные интерфейсы можно комбинировать; достаточно богатый интерфейс приложения может поддерживать и другие интерфейсы. [3]

Это наблюдение привело к созданию API, поддерживающих все типы программирования, а не только прикладное программирование. К 1990 году технолог Карл Маламуд определил API просто как «набор сервисов, доступных программисту для выполнения определенных задач» . [9]

Концепция API была снова расширена с появлением веб-API . В диссертации Роя Филдинга « Архитектурные стили и проектирование сетевых архитектур программного обеспечения в Калифорнийском университете в Ирвине в 2000 году» описана передача репрезентативного состояния (REST) ​​и описана идея «сетевого интерфейса прикладного программирования», который Филдинг противопоставляет традиционным «библиотечным». на основе "API. [10] Веб-API XML и JSON получили широкое коммерческое распространение с 2000 года и продолжаются по состоянию на 2021 год.

Веб-API теперь является наиболее распространенным значением термина API. [11] При таком использовании термин «API» частично совпадает по значению с терминами « протокол связи» и « удаленный вызов процедуры» .

Использование [ править ]

Библиотеки и фреймворки [ править ]

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

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

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

Использование API может варьироваться в зависимости от типа используемого языка программирования. API для процедурного языка, такого как Lua, может состоять в основном из базовых подпрограмм для выполнения кода, управления данными или обработки ошибок, в то время как API для объектно-ориентированного языка , такого как Java, предоставит спецификацию классов и их методов класса . [13] [14]

Привязки языков также являются API. Сопоставляя функции и возможности одного языка с интерфейсом, реализованным на другом языке, языковая привязка позволяет использовать библиотеку или службу, написанную на одном языке, при разработке на другом языке. [15] Такие инструменты, как SWIG и F2PY, генератор интерфейса Fortran- to- Python , облегчают создание таких интерфейсов. [16]

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

Более того, общий поток управления программой может быть вне контроля вызывающей стороны и в руках фреймворка посредством инверсии управления или аналогичного механизма. [17] [18]

Операционные системы [ править ]

API может определять интерфейс между приложением и операционной системой . [19] POSIX , например, определяет набор общих API-интерфейсов, которые позволяют компилировать приложение, написанное для POSIX-совместимой операционной системы, для другой POSIX-совместимой операционной системы.

Linux и Berkeley Software Distribution являются примерами операционных систем, реализующих API POSIX. [20]

Microsoft продемонстрировала твердую приверженность обратно-совместимому API, особенно в своей библиотеке Windows API (Win32), поэтому более старые приложения могут работать в более новых версиях Windows с использованием параметра, зависящего от исполняемого файла, который называется «Режим совместимости». [21]

API отличается от двоичного интерфейса приложения (ABI) тем, что API основан на исходном коде, а ABI - на двоичном . Например, POSIX предоставляет API, а Linux Standard Base предоставляет ABI. [22] [23]

Удаленные API [ править ]

Удаленные API-интерфейсы позволяют разработчикам управлять удаленными ресурсами с помощью протоколов , определенных стандартов связи, которые позволяют различным технологиям работать вместе, независимо от языка или платформы. Например, API подключения к базам данных Java позволяет разработчикам запрашивать множество различных типов баз данных с одним и тем же набором функций, в то время как API вызова удаленных методов Java использует протокол удаленного метода Java, чтобы разрешить вызов функций, которые работают удаленно, но кажутся локальными для разработчик. [24] [25]

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

Модификация прокси-объекта также приведет к соответствующей модификации удаленного объекта. [26]

Веб-API [ править ]

Основная статья: Веб-API

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

При использовании в контексте веб-разработки API обычно определяется как набор спецификаций, таких как сообщения запроса протокола передачи гипертекста (HTTP), вместе с определением структуры сообщений ответа, обычно на расширяемом языке разметки ( XML ) или в формате JavaScript Object Notation ( JSON ). Примером может служить API транспортной компании, который можно добавить на веб-сайт, ориентированный на электронную коммерцию, чтобы упростить заказ услуг доставки и автоматически включать текущие тарифы на доставку, без необходимости разработчика сайта вводить таблицу тарифов грузоотправителя в веб-базу данных. Хотя «веб-API» исторически был практически синонимом веб-службы , недавняя тенденция (так называемая Веб 2.0) отходит от веб-сервисов на основе простого протокола доступа к объектам ( SOAP ) и сервис-ориентированной архитектуры (SOA) к веб-ресурсам в стиле прямой репрезентативной передачи состояния (REST) и ресурсо-ориентированной архитектуре (ROA). [28] Частично эта тенденция связана с движением семантической паутины к Resource Description Framework (RDF), концепции продвижения технологий разработки онтологий на основе Интернета . Веб-API позволяют комбинировать несколько API-интерфейсов в новые приложения, известные как гибридные приложения . [29]В пространстве социальных сетей веб-API позволили веб-сообществам облегчить обмен контентом и данными между сообществами и приложениями. Таким образом, контент, который динамически создается в одном месте, можно публиковать и обновлять в нескольких местах в Интернете. [30] Например, REST API Twitter позволяет разработчикам получать доступ к основным данным Twitter, а Search API предоставляет разработчикам методы взаимодействия с данными поиска Twitter и тенденциями. [31]

Дизайн [ править ]

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

Политика выпуска [ править ]

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

Основные правила выпуска API: [35]

  • Частный : API предназначен только для внутреннего использования компанией.
  • Партнер : API могут использовать только определенные деловые партнеры. Например, компании по аренде автомобилей, такие как Uber и Lyft, позволяют утвержденным сторонним разработчикам напрямую заказывать поездки из своих приложений. Это позволяет компаниям осуществлять контроль качества, определяя, какие приложения имеют доступ к API, и обеспечивает им дополнительный поток доходов. [36]
  • Публичный : API доступен для публичного использования. Например, Microsoft делает Windows API общедоступным, а Apple выпускает свой API Cocoa , чтобы программное обеспечение можно было писать для их платформ . Не все общедоступные API доступны всем. Например, интернет-провайдеры, такие как Cloudflare или Voxility, используют RESTful API, чтобы позволить клиентам и торговым посредникам получать доступ к информации об их инфраструктуре, статистике DDoS, производительности сети или элементам управления панелью управления. [37] Доступ к таким API предоставляется либо с помощью «токенов API», либо с помощью проверки статуса клиента. [38]

Последствия для публичного API [ править ]

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

Когда части публично представленного API могут быть изменены и, следовательно, нестабильны, такие части конкретного API должны быть явно задокументированы как «нестабильные». Например, в библиотеке Google Guava части, которые считаются нестабильными и которые могут скоро измениться, отмечены аннотацией Java @Beta . [40]

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

Клиентский код может содержать новаторские или гибкие способы использования, которые не были предусмотрены разработчиками API. Другими словами, для библиотеки со значительной базой пользователей, когда элемент становится частью общедоступного API, его можно использовать по-разному. [42] 19 февраля 2020 года Akamai опубликовала свой ежегодный отчет «Состояние Интернета», демонстрирующий растущую тенденцию киберпреступников, нацеленных на публичные платформы API в финансовых службах по всему миру. С декабря 2017 года по ноябрь 2019 года Akamai стал свидетелем 85,42 миллиарда атак с нарушением учетных данных. Около 20%, или 16,55 миллиарда, были против имен хостов, определенных как конечные точки API. Из них 473,5 миллиона адресованы организациям сектора финансовых услуг. [43]

Документация [ править ]

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

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

Традиционные файлы документации часто представлены через систему документации, такую ​​как Javadoc или Pydoc, которая имеет единообразный вид и структуру. Однако типы содержимого, включенного в документацию, различаются от API к API. [46]

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

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

Документацию по API можно дополнить информацией о метаданных, например, аннотациями Java . Эти метаданные могут использоваться компилятором, инструментами, а также время выполнения условий для реализации пользовательских поведения или собственной обработки. [48]

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

Споры об авторских правах [ править ]

Основная статья: Oracle America, Inc. против Google, Inc.

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

Принять претензию Oracle означало бы разрешить кому-либо создать авторское право на одну версию кода для выполнения системы команд и тем самым запретить всем другим писать ее разные версии для выполнения всех или части одних и тех же команд. [51] [52]

Однако в 2014 году решение Алсупа было отменено при подаче апелляции в Апелляционный суд Федерального округа , хотя вопрос о том, является ли такое использование API добросовестным, остался нерешенным. [53]

В 2016 году после двухнедельного судебного разбирательства жюри решило, что повторная реализация Google API Java является добросовестным использованием, но Oracle пообещала обжаловать это решение. [54] Oracle выиграла апелляцию, поскольку Апелляционный суд Федерального округа постановил, что использование Google API не соответствует требованиям добросовестного использования. [55] В 2019 году Google подал апелляцию в Верховный суд США по поводу постановлений о защите авторских прав и добросовестного использования, и Верховный суд удовлетворил требования. [56]

Примеры [ править ]

Основная категория: Интерфейсы прикладного программирования
  • ASPI для интерфейса устройства SCSI
  • Какао и углерод для Macintosh
  • DirectX для Microsoft Windows
  • EHLLAPI
  • API Java
  • ODBC для Microsoft Windows
  • Кросс-платформенный звуковой API OpenAL
  • Кроссплатформенный API OpenCL для вычислений общего назначения для процессоров и графических процессоров
  • OpenGL кросс-платформенный графический API
  • OpenMP API, который поддерживает многоплатформенное многопроцессорное программирование с общей памятью на C, C ++ и Fortran на многих архитектурах, включая платформы Unix и Microsoft Windows.
  • Интерфейс программирования серверных приложений (SAPI)
  • Простой уровень DirectMedia (SDL)

См. Также [ править ]

  • API тестирование
  • Писатель API
  • Дополненная сеть
  • Соглашение о вызове
  • Общая архитектура брокера объектных запросов (CORBA)
  • Сравнение виртуальных машин приложений
  • Объектная модель документа (DOM)
  • Функция двойного шанса
  • Интерфейс внешней функции
  • Передняя и задняя части
  • Интерфейс (вычисления)
  • Документ управления интерфейсом
  • Список API 3D-графики
  • Микросервисы
  • Изменение имени
  • Открытый API
  • Определения интерфейса открытой службы
  • Парсинг
  • Плагин
  • RAML (программное обеспечение)
  • Комплект для разработки программного обеспечения (SDK)
  • Веб-API
  • Поставщик веб-контента
  • XPCOM

Ссылки [ править ]

  1. ^ Фишер, Шарон (1989). «OS / 2 EE получит интерфейс 3270 раньше» . Google Книги .
  2. ^ a b c 3333 Кларк, Стивен (2004). «Измерение юзабилити API» . Доктора Добба . Проверено 29 июля +2016 .
  3. ^ a b Архитектуры баз данных - технико-экономическое обоснование (Отчет). Вашингтон, округ Колумбия: Министерство торговли США, Национальное бюро стандартов. Апрель 1981 г. С. 45–47. hdl : 2027 / mdp.39015077587742 . LCCN 81600004 . Специальная публикация НБС 500-76 . Проверено 18 сентября 2020 года . 
  4. ^ a b c Блох, Джошуа (8 августа 2018 г.). Краткая, содержательная история API (речь). QCon. Сан-Франциско: InfoQ . Проверено 18 сентября 2020 года .
  5. ^ a b Коттон, Ира У .; Greatorex, Фрэнк С. (декабрь 1968 г.). «Структуры данных и методы удаленной компьютерной графики» . AFIPS '68: Материалы осенней совместной компьютерной конференции 9-11 декабря 1968 года . Осенняя компьютерная конференция AFIPS 1968 года. Я . Сан-Франциско, Калифорния: Ассоциация вычислительной техники. С. 533–544. DOI : 10.1145 / 1476589.1476661 . ISBN 978-1450378994. OCLC  1175621908 .
  6. ^ "интерфейс прикладной программы" . Оксфордский словарь английского языка (Интернет-изд.). Издательство Оксфордского университета. (Требуется подписка или членство в учреждении-участнике .)
  7. ^ Дата, CJ (18 июля 2019 г.). EF Codd и теория отношений: подробный обзор и анализ основных работ Кодда по базам данных . п. 135. ISBN 978-1684705276.
  8. ^ Дата, CJ; Кодд, EF (январь 1975 г.). «Реляционный и сетевой подходы: Сравнение интерфейсов прикладного программирования» . В Рэндалле Растине (ред.). Труды семинара ACM-SIGMOD 1974 года по описанию, доступу и контролю данных . SIGMOD Workshop 1974. 2 . Анн-Арбор, Мичиган: Ассоциация вычислительной техники. С. 83–113. DOI : 10.1145 / 800297.811532 . ISBN 978-1450374187. OCLC  1175623233 .
  9. ^ Карл, Маламуд (1990). Анализ сетей Novell . Ван Ностранд Рейнхольд. п. 294. ISBN 978-0442003647.
  10. ^ Филдинг, Рой (2000). Архитектурные стили и проектирование сетевых архитектур программного обеспечения (PhD) . Проверено 18 сентября 2020 года .
  11. ↑ Лейн, Кин (10 октября 2019 г.). «Введение в API: история API» . Почтальон . Проверено 18 сентября 2020 года . Когда вы слышите аббревиатуру «API» или его расширенную версию «Application Programming Interface», это почти всегда относится к нашему современному подходу, поскольку мы используем HTTP для обеспечения доступа к машиночитаемым данным в формате JSON или XML, часто просто называемые «веб-API». API-интерфейсы существуют почти так же долго, как и вычисления, но современные веб-API начали формироваться в начале 2000-х годов.
  12. ^ Одерский, Мартин; Ложка, Лекс; Веннерс, Билл (10 декабря 2008 г.). «Объединение Scala и Java» . www.artima.com . Проверено 29 июля +2016 .
  13. ^ де Фигейредо, Луис Энрике; Иерусалимский, Роберто ; Филхо, Вальдемар Селес. «Дизайн и реализация языка для расширения приложений» . TeCGraf Grupo de Tecnologia Em Computacao Grafica . CiteSeerX 10.1.1.47.5194 . S2CID 59833827 . Проверено 29 июля +2016 .  
  14. ^ Синтес, Тони (13 июля 2001). "Что вообще такое Java API?" . JavaWorld . Проверено 18 июля 2020 .
  15. ^ Эмери, Дэвид. «Стандарты, API, интерфейсы и привязки» . Acm.org. Архивировано из оригинала на 2015-01-16 . Проверено 8 августа 2016 .
  16. ^ "F2PY.org" . F2PY.org . Проверено 18 декабря 2011 .
  17. ^ Фаулер, Мартин. «Инверсия управления» .
  18. ^ Файад, Мохамед. «Объектно-ориентированные рамки приложений» .
  19. ^ Левин, Дональд А. (1991). Руководство программиста POSIX . O'Reilly & Associates, Inc. стр. 1. ISBN 9780937175736. Проверено 2 августа 2016 .
  20. ^ Запад, Джоэл; Дедрик, Джейсон (2001). «Стандартизация с открытым исходным кодом: подъем Linux в сетевую эру» (PDF) . Знания, технологии и политика . 14 (2): 88–112 . Проверено 2 августа 2016 .
  21. ^ Microsoft (октябрь 2001 г.). «Поддержка Windows XP» . Microsoft. п. 4. Архивировано из оригинала на 2009-09-26.
  22. ^ "LSB Введение" . Linux Foundation. 21 июня 2012 . Проверено 27 марта 2015 .
  23. Перейти ↑ Stoughton, Nick (апрель 2005 г.). «Обновление стандартов» (PDF) . USENIX . Проверено 4 июня 2009 .
  24. ^ Бирхофф, Кевин (23 апреля 2009). «Соответствие протоколу API в объектно-ориентированном программном обеспечении» (PDF) . CMU Институт исследований программного обеспечения . Дата обращения 29 июля 2016 .
  25. ↑ Уилсон, М. Джефф (10 ноября 2000 г.). «Умейте использовать прокси и RMI» . JavaWorld . Проверено 18 июля 2020 .
  26. ^ Хеннинг, Мичи; Виноски, Стив (1999). Расширенное программирование CORBA с помощью C ++ . Эддисон-Уэсли . ISBN 978-0201379273. Дата обращения 16 июня 2015 .
  27. ^ "API-описание" (скачать PDF) . www.hcltech.com . Август 2014 г.
  28. ^ Benslimane, Djamal; Шахрам Дустдар; Амит Шет (2008). «Мэшапы служб: новое поколение веб-приложений» . IEEE Internet Computing, vol. 12, вып. 5 . Институт инженеров по электротехнике и радиоэлектронике. С. 13–15. Архивировано из оригинала на 2011-09-28 . Проверено 1 октября 2019 .
  29. ^ Никколай, Джеймс (2008-04-23), «Так что же такое Enterprise Mashup?» , Мир ПК
  30. ^ Парр, Бен. «Эволюция API социальных сетей» . Mashable . Проверено 26 июля +2016 .
  31. ^ "ПОЛУЧИТЕ тенденции / место" . developer.twitter.com . Проверено 30 апреля 2020 .
  32. Перейти ↑ Parnas, DL (1972). «О критериях, которые будут использоваться при разложении систем на модули» (PDF) . Коммуникации ACM . 15 (12): 1053–1058. DOI : 10.1145 / 361598.361623 . S2CID 53856438 .  
  33. ^ Garlan, Дэвид; Шоу, Мэри (январь 1994). «Введение в архитектуру программного обеспечения» (PDF) . Достижения в области разработки программного обеспечения и инженерии знаний . 1 . Дата обращения 8 августа 2016 .
  34. ^ Де Ternay, Guerric (10 октября 2015). «Бизнес-экосистема: создание экономического рва» . BoostCompanies . Проверено 1 февраля 2016 .
  35. ^ Бойд, Марк (21 февраля 2014 г.). «Частный, партнерский или публичный: какая стратегия API лучше всего подходит для бизнеса?» . ПрограммируемыйWeb . Проверено 2 августа 2016 .
  36. ^ Weissbrot, Alison (7 июля 2016). «API-интерфейсы автосервисов есть повсюду, но что это значит для партнерских приложений?» . AdExchanger .
  37. ^ «Документация по Cloudflare API v4» . облачная вспышка . 25 февраля 2020 . Проверено 27 февраля 2020 года .
  38. ^ Лью, Zell (17 января 2018). «API автосервиса есть везде, но что в нем для партнерских приложений» . Smashing Magazine . Проверено 27 февраля 2020 года .
  39. ^ а б Ши, Линь; Чжун, Хао; Се, Дао; Ли, Миншу (2011). Эмпирическое исследование эволюции документации API . Международная конференция по фундаментальным подходам к программной инженерии . Конспект лекций по информатике. 6603 . С. 416–431. DOI : 10.1007 / 978-3-642-19811-3_29 . ISBN 978-3-642-19810-6. Дата обращения 22 июля 2016 .
  40. ^ "библиотеки guava - Guava: основные библиотеки Google для Java 1.6+ - хостинг проектов Google" . 2014-02-04 . Проверено 11 февраля 2014 .
  41. ^ Оракул. «Как и когда отказаться от API-интерфейсов» . Документация по Java SE . Проверено 2 августа 2016 .
  42. ^ Мендес, Диего; Бодри, Бенуа; Монперрус, Мартин (2013). «Эмпирическое свидетельство большого разнообразия в использовании API объектно-ориентированного программного обеспечения» . 13-я Международная рабочая конференция IEEE 2013 года по анализу и манипуляции исходным кодом (SCAM) . С. 43–52. arXiv : 1307,4062 . DOI : 10,1109 / SCAM.2013.6648183 . ISBN 978-1-4673-5739-5. S2CID  6890739 .
  43. ↑ Таканаши, Дин (19 февраля 2020 г.). «Akamai: киберпреступники атакуют API-интерфейсы финансовых компаний» . Венчурный бит . Проверено 27 февраля 2020 года .
  44. ^ Декель, Ури; Хербслеб, Джеймс Д. (май 2009 г.). «Повышение удобства использования документации API с помощью распространения знаний». Институт исследований программного обеспечения, Школа компьютерных наук . CiteSeerX 10.1.1.446.4214 . 
  45. ^ Парнин, Крис; Treude, Кристоф (май 2011 г.). «Документация по API измерений в сети» . Web2SE : 25–30. DOI : 10.1145 / 1984701.1984706 . ISBN 9781450305952. S2CID  17751901 . Дата обращения 22 июля 2016 .
  46. ^ Маалей, Валид; Робиллард, Мартин П. (апрель 2012 г.). «Шаблоны знаний в справочной документации API» (PDF) . IEEE Transactions по разработке программного обеспечения . Дата обращения 22 июля 2016 .
  47. ^ Монперрус, Мартин; Эйхберг, Майкл; Текес, Элиф; Мезини, Мира (3 декабря 2011 г.). «Что должны знать разработчики? Эмпирическое исследование директив документации API». Эмпирическая программная инженерия . 17 (6): 703–737. arXiv : 1205,6363 . DOI : 10.1007 / s10664-011-9186-4 . S2CID 8174618 . 
  48. ^ «Аннотации» . Sun Microsystems . Архивировано из оригинала на 2011-09-25 . Проверено 30 сентября 2011 ..
  49. ^ Брух, Марсель; Мезини, Мира; Монперрус, Мартин (2010). «Директивы создания подклассов для улучшения повторного использования фреймворка». 2010 7-я рабочая конференция IEEE по репозиториям программного обеспечения для майнинга (MSR 2010) . С. 141–150. CiteSeerX 10.1.1.434.15 . DOI : 10.1109 / msr.2010.5463347 . ISBN  978-1-4244-6802-7. S2CID  1026918 .
  50. ^ «Oracle и конец программирования, каким мы его знаем» . DrDobbs. 2012-05-01 . Проверено 9 мая 2012 .
  51. ^ «API-интерфейсы не могут быть защищены авторским правом, - говорит судья в деле Oracle» . TGDaily. 2012-06-01 . Проверено 6 декабря 2012 .
  52. ^ «Oracle America, Inc. против Google Inc» (PDF) . Проводной . 2012-05-31 . Проверено 22 сентября 2013 .
  53. Рианна Розенблатт, Сет (9 мая 2014 г.). «Суд встал на сторону Oracle по Android в апелляции на патент Java» . CNET . Проверено 10 мая 2014 .
  54. ^ "Google превосходит Oracle - Android" добросовестно использует "Java API" . Ars Technica . 2016-05-26 . Проверено 28 июля 2016 .
  55. ↑ Декер, Сьюзен (27 марта 2018 г.). «Oracle выигрывает возрождение дела на миллиард долларов против Google» . Bloomberg Businessweek . Проверено 27 марта 2018 года .
  56. ↑ Ли, Тимоти (25 января 2019 г.). «Google просит Верховный суд отменить катастрофическое решение по авторским правам API» . Ars Technica . Проверено 8 февраля 2019 года .

Дальнейшее чтение [ править ]

  • Тайна Бучер (16 ноября 2013 г.). «Объекты интенсивного переживания: случай API Twitter» . Вычислительная культура (3). ISSN  2047-2390 . Утверждает, что «API - это далеко не нейтральные инструменты» и составляют ключевую часть современного программирования, понимаемую как фундаментальную часть культуры.