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

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

API-интерфейсы берут свое начало в стремлении к независимости от оборудования , восходя в конкретной форме к сообществу программистов, которое сформировалось вокруг Univac 1108 , впервые представленного в 1964 году.

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

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

В первые дни доминировал аппаратный API. Хорошим примером является программная среда CP / M, по существу, основанная на стандарте шины S-100 1974 года, в начале эры персональных компьютеров .

По мере того, как ПК становились все более мощными, более мощные операционные системы стали предлагать оконные пользовательские среды, в которых можно было запускать сложное прикладное программное обеспечение . Ранними примерами были классическая Mac OS, представленная в 1984 году, и Microsoft Windows, представленная в рудиментарной форме в 1985 году. Традиционно операционные системы абстрагируются от устройств (таких как дисководы, принтеры и модемы). Постепенно пользовательские устройства, такие как музыкальные инструменты с MIDI- интерфейсами, игровые контроллеры 1980- х годов и периферийные USB- устройства 1990-х годов, все больше абстрагировались драйверами устройств операционной системы , важным уровнем API, внутренним по отношению к самой операционной системе.

На стороне сервера философия Unix, разработанная Кеном Томпсоном из Bell Labs в начале 1970-х годов, остается доминирующим стандартом программного обеспечения. С появлением общедоступного Интернета в 1990-х годах, основанного на сетевых протоколах Unix , веб-API стали доминирующей парадигмой программирования.

В 2005 году Google начал развертывать асинхронные веб-приложения, а в 2007 году Стив Джобс сделал HTML5 и AJAX центральной парадигмой программирования iPhone, в то время как телефоны Google Android переняли ту же философию. Когда мобильная экология стала доминировать в повседневном использовании, JavaScriptприобрела все большую известность в среде HTML5, а программные API-интерфейсы, ориентированные на использование сети, теперь распространились почти во все сферы человеческого предприятия. В отличие от эпохи настольных компьютеров, когда настольное приложение могло преимущественно кодироваться для ОС одного производителя, даже относительно простое мобильное приложение часто кодируется поверх всего набора связанных и перекрывающихся API-интерфейсов программных компонентов, включая то, что сейчас часто называют стеком решений .

Концепция API не ограничивается аппаратным обеспечением и кодом. Semantic Web , как введенный Тим Бернерс-Ли в 2001 году был предложение угощения программирования сети как API обернутым вокруг лежащих в основе данных самостоятельно , а не поведение системы с целью к эволюции интеллектуальных агентов в качестве открытой инноваций предпринимательской экосистемы . Вместо этого теперь у нас есть проприетарные агенты, такие как Amazon Alexa и Siri, которые предоставляют пользовательские интерфейсы на естественном языке, а не программные API, - это совершенно другая инженерная позиция по отношению к человеческому интерфейсуграница. Википедия - известный интернет-проект, который поддерживает программные API с семантическим привкусом (см. MediaWiki API: Главная страница и Semantic MediaWiki ).

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

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

Также возникают юридические проблемы, связанные с владением API. После покупки Oracle Sun Microsystems в 2009 году, которая включала язык программирования Sun Java , Oracle подала иск против Google, утверждая, что API защищены авторским правом , требуя возмещения убытков в размере 8,8 миллиардов долларов США от продаж Google и лицензирования более ранних версий Android, нарушающих авторские права [2 ] . Из -за пандемии COVID-19 устные слушания по делу были отложены до октября 2020 года. Судебные наблюдатели обнаружили, что, хотя судьи, казалось, были на стороне Oracle в аргументах об авторском праве, они также с уважением относились к аргументам, представленным Microsoft.. Microsoft заявила в дружеской записке, что решение в пользу Oracle может перевернуть индустрию программного обеспечения. Несколько вопросов касались того, как API подпадают под различие между идеей и выражением авторского права и применима ли доктрина слияния.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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