stringtranslate.com

API

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

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

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

Термин API часто используется для обозначения веб-API , [2] которые позволяют осуществлять связь между компьютерами, подключенными к Интернету . Существуют также API для языков программирования , библиотек программного обеспечения , компьютерных операционных систем и компьютерного оборудования . API возникли в 1940-х годах, хотя сам термин появился только в 1960-х и 1970-х годах.

Цель

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

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

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

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

В качестве примера рассмотрим датчик погоды, который предлагает API. Когда определенное сообщение передается датчику, он определяет текущие погодные условия и отвечает прогнозом погоды. Сообщение, которое активирует датчик, является вызовом API , а прогноз погоды является ответом API . [7] Приложение прогнозирования погоды может интегрироваться с несколькими API датчиков погоды, собирая данные о погоде со всей географической области.

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

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

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

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

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

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

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

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

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

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

Скриншот документации Web API , написанной NASA

Идея API снова была расширена с рассветом удаленных вызовов процедур и веб-API . Поскольку компьютерные сети стали обычным явлением в 1970-х и 80-х годах, программисты хотели вызывать библиотеки, расположенные не только на их локальных компьютерах, но и на компьютерах, расположенных в других местах. Эти удаленные вызовы процедур хорошо поддерживались языком Java , в частности. В 1990-х годах, с распространением Интернета , такие стандарты, как CORBA , COM и DCOM, конкурировали за то, чтобы стать наиболее распространенным способом предоставления API-сервисов. [16]

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

Семантическая паутина, предложенная Тимом Бернерсом-Ли в 2001 году, включала «семантические API», которые переделывали API как открытый , распределенный интерфейс данных, а не интерфейс поведения программного обеспечения. [18] Проприетарные интерфейсы и агенты стали более распространенными, чем открытые, но идея API как интерфейса данных укрепилась. Поскольку веб-API широко используются для обмена данными всех видов в сети, API стал широким термином, описывающим большую часть общения в Интернете. [16] При таком использовании термин API имеет совпадение по значению с термином протокол связи .

Типы

Библиотеки и фреймворки

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

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

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

Использование API может варьироваться в зависимости от типа используемого языка программирования. API для процедурного языка, такого как Lua, может состоять в основном из базовых процедур для выполнения кода, манипулирования данными или обработки ошибок, в то время как API для объектно-ориентированного языка , такого как Java, будет предоставлять спецификацию классов и их методов класса . [20] [21] Закон Хайрама гласит, что «при достаточном количестве пользователей API не имеет значения, что вы обещаете в контракте: все наблюдаемые поведения вашей системы будут зависеть от кого-то». [22] Между тем, несколько исследований показывают, что большинство приложений, использующих API, как правило, используют лишь небольшую часть API. [23]

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

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

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

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

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

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

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

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

Удаленные API

Удаленные API позволяют разработчикам манипулировать удаленными ресурсами через протоколы , специальные стандарты для связи, которые позволяют различным технологиям работать вместе, независимо от языка или платформы. Например, Java Database Connectivity API позволяет разработчикам запрашивать множество различных типов баз данных с тем же набором функций, в то время как Java remote method invocation API использует Java Remote Method Protocol, чтобы разрешить вызов функций, которые работают удаленно, но кажутся разработчику локальными. [33] [34]

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

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

Веб-API

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

При использовании в контексте веб-разработки API обычно определяется как набор спецификаций, таких как сообщения-запросы протокола передачи гипертекста (HTTP), а также определение структуры ответных сообщений, обычно в формате Extensible Markup Language ( XML ) или JavaScript Object Notation ( JSON ). Примером может служить API судоходной компании, который можно добавить на веб-сайт, ориентированный на электронную коммерцию, чтобы упростить заказ услуг по доставке и автоматически включать текущие тарифы на доставку, без необходимости для разработчика сайта вводить таблицу тарифов грузоотправителя в веб-базу данных. Хотя «веб-API» исторически был фактически синонимом веб-сервиса , недавняя тенденция (так называемый Web 2.0 ) отходит от веб-сервисов на основе Simple Object Access Protocol ( SOAP ) и сервисно-ориентированной архитектуры (SOA) к веб-ресурсам в стиле более прямой передачи репрезентативного состояния (REST) ​​и ресурсно-ориентированной архитектуре (ROA). [37] Часть этой тенденции связана с движением Semantic Web к Resource Description Framework (RDF), концепции продвижения веб- технологий разработки онтологий . Веб-API позволяют объединять несколько API в новые приложения, известные как mashups . [38] В пространстве социальных сетей веб-API позволили веб-сообществам облегчить обмен контентом и данными между сообществами и приложениями. Таким образом, контент, который создается в одном месте динамически, может быть опубликован и обновлен в нескольких местах в сети. [39] Например, REST API Twitter позволяет разработчикам получать доступ к основным данным Twitter, а Search API предоставляет разработчикам методы для взаимодействия с данными поиска и трендов Twitter. [40]

Дизайн

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

Политика выпуска

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

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

Последствия публичного API

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

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

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

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

Документация

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

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

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

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

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

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

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

Спор о защите авторских прав на API

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

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

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

В 2016 году после двухнедельного судебного разбирательства присяжные постановили, что повторная реализация Google API Java представляет собой добросовестное использование , но Oracle пообещала обжаловать это решение. [64] Oracle выиграла апелляцию, и Апелляционный суд Федерального округа постановил, что использование Google API не соответствует критериям добросовестного использования. [65] В 2019 году Google подала апелляцию в Верховный суд США по поводу решений как о нарушении авторских прав, так и о добросовестном использовании, и Верховный суд удовлетворил ходатайство о пересмотре. [66] Из-за пандемии COVID-19 устные слушания по делу были отложены до октября 2020 года. [67]

Дело было решено Верховным судом в пользу Google. [68]

Примеры

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

Ссылки

  1. ^ Reddy, Martin (2011). API Design for C++. Elsevier Science. стр. 1. ISBN 9780123850041.
  2. ^ ab Lane, Kin (10 октября 2019 г.). "Введение в API: история API". Postman . Получено 18 сентября 2020 г. Когда вы слышите аббревиатуру "API" или ее расширенную версию "Application Programming Interface", это почти всегда относится к нашему современному подходу, в котором мы используем HTTP для предоставления доступа к машиночитаемым данным в формате JSON или XML, часто называемым просто "веб-API". API существуют почти так же долго, как и вычисления, но современные веб-API начали формироваться в начале 2000-х годов.
  3. ^ ab Педро, Бруно (2024). Создание продукта API: проектирование, реализация, выпуск и поддержка продуктов API, которые отвечают потребностям пользователей. Packt Publishing. стр. 4. ISBN 9781837638536.
  4. ^ Биль, Маттиас (2016). RESTful API Design . API-University Press. стр. 10. ISBN 9781514735169.
  5. ^ abc Кларк, Стивен (2004). "Измерение удобства использования API". Dr. Dobb's . Получено 29 июля 2016 г.
  6. ^ Джин, Бренда; Сахни, Саурабх; Шеват, Амир (2018). «Предисловие». Проектирование веб-API: создание API, которые любят разработчики. O'Reilly Media. ISBN 9781492026877.
  7. ^ Geewax, JJ (2021). API Design Patterns. Manning. стр. 6. ISBN 9781638350330.
  8. ^ Якобсон, Дэниел; Брейл, Грег; Вудс, Дэн (2011). API: Руководство по стратегии. O'Reilly Media. стр. 4. ISBN 9781449321642.
  9. ^ ab Архитектуры баз данных – семинар по осуществимости (Отчет). Вашингтон, округ Колумбия: Министерство торговли США, Национальное бюро стандартов. Апрель 1981 г. С. 45–47. hdl :2027/mdp.39015077587742. LCCN  81600004. Специальная публикация NBS 500-76 . Получено 18 сентября 2020 г.
  10. ↑ abcd Блох, Джошуа (8 августа 2018 г.). Краткая и объективная история API (выступление). ККон. Сан-Франциско: InfoQ . Проверено 18 сентября 2020 г.
  11. ^ ab Cotton, Ira W.; Greatorex, Frank S. (декабрь 1968 г.). "Структуры данных и методы удаленной компьютерной графики". AFIPS '68: Труды 9–11 декабря 1968 г., Осенняя объединенная компьютерная конференция . AFIPS 1968 Осенняя объединенная компьютерная конференция. Том I. Сан-Франциско, Калифорния: Ассоциация вычислительной техники. стр. 533–544. doi :10.1145/1476589.1476661. ISBN 978-1450378994. OCLC  1175621908.
  12. ^ "интерфейс прикладной программы" . Оксфордский словарь английского языка (Электронная правка). Oxford University Press . (Требуется подписка или членство в участвующем учреждении.)
  13. ^ Дата, CJ (2019). EF Codd и реляционная теория: подробный обзор и анализ основных трудов Кодда по базам данных. Lulu.com. стр. 135. ISBN 978-1684705276.
  14. ^ Дата, CJ; Кодд, EF (январь 1975). "Реляционный и сетевой подходы: сравнение интерфейсов прикладного программирования". В Рэндалле Растине (ред.). Труды семинара ACM-SIGMOD 1974 года по описанию данных, доступу и управлению . Семинар SIGMOD 1974. Том 2. Энн-Арбор, Мичиган: Ассоциация вычислительной техники. стр. 83–113. doi :10.1145/800297.811532. ISBN 978-1450374187. OCLC  1175623233.
  15. ^ Карл, Маламуд (1990). Анализ сетей Novell. Van Nostrand Reinhold. стр. 294. ISBN 978-0442003647.
  16. ^ Аб Джин, Бренда; Сахни, Саураб; Шват, Амир (2018). Проектирование веб-API. О'Рейли Медиа. ISBN 9781492026877.
  17. ^ Филдинг, Рой (2000). Архитектурные стили и проектирование сетевых программных архитектур (PhD) . Получено 18 сентября 2020 г.
  18. ^ Дотсика, Фефи (август 2010 г.). «Семантические API: масштабирование в сторону семантической паутины». Международный журнал по управлению информацией . 30 (4): 335–342. doi :10.1016/j.ijinfomgt.2009.12.003.
  19. ^ Одерски, Мартин; Спун, Лекс; Веннерс, Билл (10 декабря 2008 г.). «Объединение Scala и Java». www.artima.com . Получено 29 июля 2016 г. .
  20. ^ де Фигейредо, Луис Энрике; Иерусалимский, Роберто ; Фильо, Вальдемар Селес (1994). «Разработка и реализация языка расширения приложений». TeCGraf Grupo de Tecnologia Em Computacao Grafica : 273–284. CiteSeerX 10.1.1.47.5194 . S2CID  59833827 . Проверено 29 июля 2016 г. 
  21. ^ Синтес, Тони (13 июля 2001 г.). «Что же такое Java API?». JavaWorld . Получено 18 июля 2020 г.
  22. ^ Уинтерс, Титус; Том Маншрек; Хайрам Райт, ред. (2020). Программная инженерия в Google: уроки, извлеченные из программирования с течением времени . Севастополь, Калифорния: O'Reilly Media. ISBN 9781492082798. OCLC  1144086840.
  23. ^ Мастранджело, Луис; Понзанелли, Лука; Моччи, Андреа; Ланца, Мишель; Хаусвирт, Маттиас; Нистром, Натаниэль (2015-10-23). ​​«Используйте на свой страх и риск: небезопасный API Java в дикой природе». Труды Международной конференции ACM SIGPLAN 2015 года по объектно-ориентированному программированию, системам, языкам и приложениям . OOPSLA 2015. Нью-Йорк, Нью-Йорк, США: Ассоциация вычислительной техники. стр. 695–710. doi :10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  24. ^ Эмери, Дэвид. «Стандарты, API, интерфейсы и привязки». Acm.org. Архивировано из оригинала 2015-01-16 . Получено 2016-08-08 .
  25. ^ "F2PY.org". F2PY.org . Получено 2011-12-18 .
  26. ^ Фаулер, Мартин. «Инверсия управления».
  27. ^ Файад, Мохамед. «Объектно-ориентированные прикладные фреймворки».
  28. ^ Левин, Дональд А. (1991). Руководство программиста POSIX. O'Reilly & Associates, Inc. стр. 1. ISBN 9780937175736. Получено 2 августа 2016 г.
  29. ^ Уэст, Джоэл; Дедрик, Джейсон (2001). «Стандартизация открытого исходного кода: рост Linux в эпоху сетей» (PDF) . Знания, технологии и политика . 14 (2): 88–112. doi :10.1007/PL00022278 . Получено 2 августа 2016 г. .
  30. ↑ Microsoft (октябрь 2001 г.). «Поддержка Windows XP». Microsoft. стр. 4. Архивировано из оригинала 2009-09-26.
  31. ^ "LSB Introduction". Linux Foundation. 21 июня 2012 г. Получено 27.03.2015 г.
  32. ^ Стоутон, Ник (апрель 2005 г.). "Обновление стандартов" (PDF) . USENIX . Получено 04.06.2009 .
  33. ^ Бирхофф, Кевин (23 апреля 2009 г.). "Соответствие протоколам API в объектно-ориентированном программном обеспечении" (PDF) . Институт исследований программного обеспечения CMU . Получено 29 июля 2016 г. .
  34. ^ Уилсон, М. Джефф (10 ноября 2000 г.). «Поумнейте с прокси и RMI». JavaWorld . Получено 18 июля 2020 г.
  35. ^ Хеннинг, Мичи; Виноски, Стив (1999). Advanced CORBA Programming with C++ . Addison-Wesley . ISBN 978-0201379273. Получено 16 июня 2015 г.
  36. ^ "API-fication" (загрузка PDF) . www.hcltech.com . Август 2014 г.
  37. ^ Бенслиман, Джамал; Шахрам Дустдар; Амит Шет (2008). «Сервисные гибридные приложения: новое поколение веб-приложений». IEEE Internet Computing, т. 12, № 5. Институт инженеров по электротехнике и электронике. стр. 13–15. Архивировано из оригинала 28.09.2011 . Получено 01.10.2019 .
  38. ^ Николаи, Джеймс (2008-04-23), «Так что же такое корпоративный мэшап?», PC World
  39. ^ Парр, Бен (21 мая 2009 г.). «Эволюция API социальных сетей». Mashable . Получено 26 июля 2016 г.
  40. ^ "GET trends/place". developer.twitter.com . Получено 2020-04-30 .
  41. ^ Парнас, Д. Л. (1972). «О критериях, используемых при разложении систем на модули» (PDF) . Сообщения ACM . 15 (12): 1053–1058. doi :10.1145/361598.361623. S2CID  53856438.
  42. ^ Гарлан, Дэвид; Шоу, Мэри (январь 1994 г.). "Введение в архитектуру программного обеспечения" (PDF) . Достижения в области программной инженерии и инженерии знаний . 1. Получено 8 августа 2016 г.
  43. ^ de Ternay, Guerric (10 октября 2015 г.). «Бизнес-экосистема: создание экономического рва». BoostCompanies . Получено 01.02.2016 .
  44. ^ Бойд, Марк (21.02.2014). «Частный, партнерский или публичный: какая стратегия API лучше всего подходит для бизнеса?». ProgrammableWeb . Получено 2 августа 2016 г.
  45. ^ Вайсброт, Элисон (7 июля 2016 г.). «API автосервисов повсюду, но что в этом для партнерских приложений?». AdExchanger .
  46. ^ "Cloudflare API v4 Documentation". cloudflare . 25 февраля 2020 г. . Получено 27 февраля 2020 г. .
  47. ^ Лью, Зелл (17 января 2018 г.). «API-интерфейсы автомобильных сервисов повсюду, но что в них для приложений-партнеров». Журнал Smashing Magazine . Получено 27 февраля 2020 г.
  48. ^ ab Shi, Lin; Zhong, Hao; Xie, Tao; Li, Mingshu (2011). Эмпирическое исследование эволюции документации API. Lecture Notes in Computer Science. Vol. 6603. Международная конференция по фундаментальным подходам к программной инженерии. стр. 416–431. doi :10.1007/978-3-642-19811-3_29. ISBN 978-3-642-19810-6. Получено 22 июля 2016 г.
  49. ^ "guava-libraries – Guava: основные библиотеки Google для Java 1.6+ – хостинг проектов Google". 2014-02-04 . Получено 2014-02-11 .
  50. ^ Oracle. "Как и когда прекращать поддержку API". Документация Java SE . Получено 2 августа 2016 г.
  51. ^ Мендес, Диего; Бодри, Бенуа; Монперрус, Мартин (2013). «Эмпирические доказательства масштабного разнообразия в использовании API объектно-ориентированного программного обеспечения». 2013 IEEE 13-я Международная рабочая конференция по анализу и обработке исходного кода (SCAM) . стр. 43–52. arXiv : 1307.4062 . doi : 10.1109/SCAM.2013.6648183. ISBN 978-1-4673-5739-5. S2CID  6890739.
  52. ^ Таканаши, Дин (19 февраля 2020 г.). «Akamai: Киберпреступники атакуют API в компаниях финансовых услуг». Venture Beat . Получено 27 февраля 2020 г.
  53. ^ Декель, Ури; Хербслеб, Джеймс Д. (май 2009 г.). «Улучшение удобства использования документации API с помощью распространения знаний». Институт исследований программного обеспечения, Школа компьютерных наук . CiteSeerX 10.1.1.446.4214 . 
  54. ^ Парнин, Крис; Треуде, Кристоф (май 2011 г.). «Измерение документации API в Интернете». Труды 2-го Международного семинара по Web 2.0 для разработки программного обеспечения . С. 25–30. doi :10.1145/1984701.1984706. ISBN 9781450305952. S2CID  17751901 . Получено 22 июля 2016 г. . {{cite book}}: |journal=проигнорировано ( помощь )
  55. ^ Maalej, Waleed; Robillard, Martin P. (апрель 2012 г.). "Patterns of Knowledge in API Reference Documentation" (PDF) . IEEE Transactions on Software Engineering . Получено 22 июля 2016 г. .
  56. ^ Монперрус, Мартин; Эйхберг, Михаэль; Текес, Элиф; Мезини, Мира (3 декабря 2011 г.). «О чем должны знать разработчики? Эмпирическое исследование директив документации API». Эмпирическая программная инженерия . 17 (6): 703–737. arXiv : 1205.6363 . doi : 10.1007/s10664-011-9186-4. S2CID  8174618.
  57. ^ "Аннотации". Sun Microsystems . Архивировано из оригинала 2011-09-25 . Получено 2011-09-30 ..
  58. ^ Брух, Марсель; Мезини, Мира; Монперрус, Мартин (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.
  59. ^ "Oracle и конец программирования, каким мы его знаем". DrDobbs. 2012-05-01 . Получено 2012-05-09 .
  60. ^ «API не могут быть защищены авторским правом, говорит судья в деле Oracle». TGDaily. 2012-06-01 . Получено 2012-12-06 .
  61. ^ "Oracle America, Inc. против Google Inc" (PDF) . Wired . 2012-05-31 . Получено 2013-09-22 .
  62. ^ «Oracle Am., Inc. против Google Inc., № 13-1021, Федеральный округ 2014 г.».
  63. ^ Розенблатт, Сет (9 мая 2014 г.). «Суд встал на сторону Oracle в апелляции по патенту Android на Java». CNET . Получено 10 мая 2014 г.
  64. ^ "Google побеждает Oracle – Android «честно использует» API Java". Ars Technica . 2016-05-26 . Получено 2016-07-28 .
  65. ^ Деккер, Сьюзан (27 марта 2018 г.). «Oracle выигрывает возрождение дела против Google на миллиард долларов». Bloomberg Businessweek . Получено 27 марта 2018 г.
  66. ^ Ли, Тимоти (25 января 2019 г.). «Google просит Верховный суд отменить катастрофическое решение об авторских правах API». Ars Technica . Получено 8 февраля 2019 г.
  67. ^ vkimber (28.09.2020). "Google LLC против Oracle America, Inc". LII / Институт юридической информации . Получено 06.03.2021 .
  68. ^ «Верховный суд Соединенных Штатов, № 18–956, GOOGLE LLC, истец против ORACLE AMERICA, INC» (PDF) . 5 апреля 2021 г.

Дальнейшее чтение

Внешние ссылки