stringtranslate.com

API

Скриншот документации Web API , написанной NASA, демонстрирующей использование APOD

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

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

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

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

API должны быть версионными . Существует две общие стратегии версионирования: [4]

Цель

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

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

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

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

1940-е и 1950-е годы

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

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

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

1960-е и 1970-е годы

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

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

Это наблюдение привело к появлению API, которые поддерживали все типы программирования, а не только прикладное программирование.

1990-е

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

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

2000-е

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

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

Использование

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

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

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

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

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

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

Такие инструменты, как SWIG и F2PY, генератор интерфейсов Fortran - Python , облегчают создание таких интерфейсов. [21]

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

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

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

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

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

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

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

Удаленные API

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

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

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

Веб-API

Веб-API — это сервис, доступ к которому осуществляется с клиентских устройств (мобильных телефонов, ноутбуков и т. д.) на веб-сервер с использованием протокола передачи гипертекста (HTTP). Клиентские устройства отправляют запрос в форме HTTP-запроса и получают ответное сообщение, как правило, в формате JavaScript Object Notation ( JSON ) или Extensible Markup Language ( XML ). Разработчики обычно используют веб-API для запроса сервера на получение определенного набора данных с этого сервера.

Примером может служить API судоходной компании, который можно добавить на веб-сайт, ориентированный на электронную коммерцию, чтобы упростить заказ услуг по доставке и автоматически включать текущие ставки доставки, без необходимости для разработчика сайта вводить таблицу ставок грузоотправителя в веб-базу данных. Хотя «Web API» исторически был фактически синонимом веб-сервиса , недавняя тенденция (так называемый Web 2.0 ) отходит от веб-сервисов на основе Simple Object Access Protocol ( SOAP ) и сервисно-ориентированной архитектуры (SOA) к веб-ресурсам в стиле более прямой передачи репрезентативного состояния (REST) ​​и ресурсно-ориентированной архитектуре (ROA). [32] Часть этой тенденции связана с движением Semantic Web к Resource Description Framework (RDF), концепции продвижения технологий веб- инжиниринга онтологий . Веб-API позволяют объединять несколько API в новые приложения, известные как mashups . [33]

В пространстве социальных сетей веб-API позволили веб-сообществам облегчить обмен контентом и данными между сообществами и приложениями. Таким образом, контент, который создается в одном месте динамически, может быть опубликован и обновлен в нескольких местах в Интернете. [34] Например, REST API Twitter позволяет разработчикам получать доступ к основным данным Twitter, а Search API предоставляет разработчикам методы для взаимодействия с данными поиска и трендов Twitter. [35]

Дизайн

Дизайн API оказывает значительное влияние на его использование. [5] Прежде всего, дизайн интерфейсов программирования представляет собой важную часть архитектуры программного обеспечения , организацию сложного фрагмента программного обеспечения. [36] Принцип сокрытия информации описывает роль интерфейсов программирования как обеспечение модульного программирования путем сокрытия деталей реализации модулей, чтобы пользователям модулей не нужно было понимать сложности внутри модулей. [37] Помимо предыдущего базового принципа, другие метрики для измерения удобства использования API могут включать такие свойства, как функциональная эффективность, общая корректность и обучаемость для новичков. [38] Один из простых и общепринятых способов проектирования API — следовать рекомендациям Нильсена по эвристической оценке. Шаблон метода Factory также типичен для проектирования API из-за их повторно используемой природы. [39] Таким образом, проектирование API пытается предоставить только те инструменты, которые ожидает пользователь. [5]

Синхронный против асинхронного

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

Безопасность

Безопасность API очень важна при разработке API, ориентированного на публику. Распространенные угрозы включают SQL-инъекцию , атаку типа «отказ в обслуживании» (DoS), сломанную аутентификацию и раскрытие конфиденциальных данных. [41] Без обеспечения надлежащих мер безопасности злоумышленники могут получить доступ к информации, которой у них не должно быть, или даже получить привилегии для внесения изменений на ваш сервер. Некоторые распространенные меры безопасности включают надлежащую безопасность соединения с использованием HTTPS , безопасность контента для смягчения атак внедрения данных и требование ключа API для использования вашего сервиса. [42] Многие службы API, ориентированные на публику, требуют от вас использования назначенного ключа API и откажутся предоставлять данные, если вы не отправите ключ вместе с вашим запросом. [43]

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

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

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

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

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

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

Публичный API иногда может объявлять части себя устаревшими или отмененными. Обычно это означает, что часть 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 обычно опускаются.

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

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

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

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

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

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

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

Дело было решено Верховным судом в пользу Google с решением 6–2. Судья Стивен Брейер огласил мнение суда и в какой-то момент упомянул, что «Декларирующий код, если он вообще подлежит авторскому праву, дальше, чем большинство компьютерных программ, отстоит от сути авторского права». Это означает, что код, используемый в API, больше похож на словари, чем на романы с точки зрения защиты авторских прав. [67]

Примеры

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

Ссылки

  1. ^ Reddy, Martin (2011). API Design for C++. Elsevier Science. стр. 1. ISBN 9780123850041. Архивировано из оригинала 2023-04-15 . Получено 2023-03-21 .
  2. ^ ab Lane, Kin (10 октября 2019 г.). "Введение в API: история API". Postman . Архивировано из оригинала 11 сентября 2020 г. . Получено 18 сентября 2020 г. . Когда вы слышите аббревиатуру "API" или ее расширенную версию "Application Programming Interface", это почти всегда относится к нашему современному подходу, в котором мы используем HTTP для предоставления доступа к машиночитаемым данным в формате JSON или XML, часто просто называемым "Web API". API существуют почти так же долго, как и вычисления, но современные Web API начали формироваться в начале 2000-х годов.
  3. ^ Вуд, Лора (2021-08-25). "Глобальный рынок облачных микросервисов (с 2021 по 2026)". businesswire.com . Архивировано из оригинала 2022-04-08 . Получено 2022-03-29 .
  4. ^ Проектирование веб-API. Создание API, которые нравятся разработчикам . O'Reilly Media. 2018. ISBN 9781492026877.
  5. ^ abc Clarke, Steven (2004). "Measuring API Usability". Dr. Dobb's . Архивировано из оригинала 3 марта 2022 г. Получено 29 июля 2016 г.
  6. ^ ab Архитектуры баз данных – семинар по осуществимости (Отчет). Вашингтон, округ Колумбия: Министерство торговли США, Национальное бюро стандартов. Апрель 1981 г. С. 45–47. hdl :2027/mdp.39015077587742. LCCN  81600004. Специальная публикация NBS 500-76 . Получено 18 сентября 2020 г.
  7. ^ abcd Блох, Джошуа (8 августа 2018 г.). Краткая, субъективная история API (речь). QCon. Сан-Франциско: InfoQ. Архивировано из оригинала 22 сентября 2020 г. Получено 18 сентября 2020 г.
  8. ^ 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. Архивировано из оригинала 20.10.2020 . Получено 19.09.2020 .
  9. ^ "интерфейс прикладной программы" . Оксфордский словарь английского языка (Электронная правка). Oxford University Press . (Требуется подписка или членство в участвующем учреждении.)
  10. ^ Дата, CJ (2019). EF Codd и реляционная теория: подробный обзор и анализ основных трудов Кодда по базам данных. Lulu.com. стр. 135. ISBN 978-1684705276.
  11. ^ Дата, CJ; Кодд, EF (январь 1975). "Реляционный и сетевой подходы: сравнение интерфейсов прикладного программирования". В Рэндалле Растине (ред.). Труды семинара ACM-SIGMOD 1974 года по описанию данных, доступу и управлению . Семинар SIGMOD 1974. Том 2. Энн-Арбор, Мичиган: Ассоциация вычислительной техники. стр. 83–113. doi :10.1145/800297.811532. ISBN 978-1450374187. OCLC  1175623233.
  12. ^ Карл, Маламуд (1990). Анализ сетей Novell. Van Nostrand Reinhold. стр. 294. ISBN 978-0442003647. Архивировано из оригинала 2021-01-26 . Получено 2020-09-19 .
  13. ^ Аб Джин, Бренда; Сахни, Саураб; Шват, Амир (2018). Проектирование веб-API. О'Рейли Медиа. ISBN 9781492026877. Архивировано из оригинала 2023-04-10 . Получено 2023-03-21 .
  14. ^ Филдинг, Рой (2000). Архитектурные стили и проектирование сетевых программных архитектур (PhD). Калифорнийский университет в Ирвайне. Архивировано из оригинала 22 января 2020 г. Получено 18 сентября 2020 г.
  15. ^ Dotsika, Fefie (август 2010 г.). «Семантические API: масштабирование в сторону семантической паутины». Международный журнал по управлению информацией . 30 (4): 335–342. doi :10.1016/j.ijinfomgt.2009.12.003.
  16. ^ Одерски, Мартин; Спун, Лекс; Веннерс, Билл (10 декабря 2008 г.). «Объединение Scala и Java». artima.com . Архивировано из оригинала 8 августа 2016 г. . Получено 29 июля 2016 г. .
  17. ^ де Фигейредо, Луис Энрике; Иерусалимский, Роберто ; Фильо, Вальдемар Селес (1994). «Разработка и реализация языка расширения приложений». TeCGraf Grupo de Tecnologia Em Computacao Grafica : 273–284. CiteSeerX 10.1.1.47.5194 . S2CID  59833827 . Проверено 29 июля 2016 г. 
  18. ^ Синтес, Тони (13 июля 2001 г.). «Что такое Java API вообще?». JavaWorld . Архивировано из оригинала 2020-10-19 . Получено 2020-07-18 .
  19. ^ Уинтерс, Титус; Том Маншрек; Хайрам Райт, ред. (2020). Программная инженерия в Google: уроки, извлеченные из программирования с течением времени . Севастополь, Калифорния: O'Reilly Media. ISBN 9781492082798. OCLC  1144086840.
  20. ^ Мастранджело, Луис; Понзанелли, Лука; Моччи, Андреа; Ланца, Мишель; Хаусвирт, Маттиас; Нистром, Натаниэль (2015-10-23). ​​«Используйте на свой страх и риск: небезопасный API Java в дикой природе». Труды Международной конференции ACM SIGPLAN 2015 года по объектно-ориентированному программированию, системам, языкам и приложениям . OOPSLA 2015. Нью-Йорк, Нью-Йорк, США: Ассоциация вычислительной техники. стр. 695–710. doi :10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  21. ^ "F2PY.org". F2PY.org. Архивировано из оригинала 2011-07-04 . Получено 2011-12-18 .
  22. ^ Фаулер, Мартин. "Инверсия управления". Архивировано из оригинала 2011-01-23 . Получено 2011-08-25 .
  23. ^ Файад, Мохамед. "Объектно-ориентированные прикладные фреймворки". Архивировано из оригинала 2013-11-05 . Получено 2013-11-05 .
  24. ^ Левин, Дональд А. (1991). Руководство программиста POSIX. O'Reilly & Associates, Inc. стр. 1. ISBN 9780937175736. Архивировано из оригинала 22 августа 2016 . Получено 2 августа 2016 .
  25. ^ Уэст, Джоэл; Дедрик, Джейсон (2001). «Стандартизация открытого исходного кода: рост Linux в эпоху сетей» (PDF) . Knowledge, Technology & Policy . 14 (2): 88–112. doi :10.1007/PL00022278. S2CID  46082812. Архивировано (PDF) из оригинала 27 августа 2016 г. . Получено 2 августа 2016 г. .
  26. ↑ Microsoft (октябрь 2001 г.). «Поддержка Windows XP». Microsoft. стр. 4. Архивировано из оригинала 26.09.2009.
  27. ^ "LSB Introduction". Linux Foundation. 21 июня 2012 г. Архивировано из оригинала 2015-04-02 . Получено 2015-03-27 .
  28. ^ Стоутон, Ник (апрель 2005 г.). "Обновление стандартов" (PDF) . USENIX . Архивировано (PDF) из оригинала 2009-03-27 . Получено 2009-06-04 .
  29. ^ Бирхофф, Кевин (23 апреля 2009 г.). Соответствие протоколам API в объектно-ориентированном программном обеспечении (PDF) (PhD). Университет Карнеги-Меллона. ISBN 978-1-109-31660-5. ProQuest  304864018. Архивировано (PDF) из оригинала 11 октября 2016 г. . Получено 29 июля 2016 г. .
  30. ^ Уилсон, М. Джефф (10 ноября 2000 г.). «Поумнейте с прокси и RMI». JavaWorld . Архивировано из оригинала 20-07-2020 . Получено 18-07-2020 .
  31. ^ Хеннинг, Мичи; Виноски, Стив (1999). Advanced CORBA Programming with C++ . Addison-Wesley . ISBN 978-0201379273. Получено 16 июня 2015 г.
  32. ^ Бенслиман, Джамал; Шахрам Дустдар; Амит Шет (2008). «Сервисные гибридные приложения: новое поколение веб-приложений». IEEE Internet Computing, т. 12, № 5. Институт инженеров по электротехнике и электронике. стр. 13–15. Архивировано из оригинала 2023-10-07 . Получено 2019-10-01 .
  33. ↑ Никколаи, Джеймс (2008-04-23), «Итак, что же такое корпоративный Mashup?», PC World , заархивировано из оригинала 10 октября 2017 г.
  34. ^ Парр, Бен (21 мая 2009 г.). «Эволюция API социальных сетей». Mashable . Архивировано из оригинала 11 августа 2016 г. Получено 26 июля 2016 г.
  35. ^ "GET trends/place". Twitter Developer Platform . Архивировано из оригинала 2020-06-17 . Получено 2020-04-30 .
  36. ^ Гарлан, Дэвид; Шоу, Мэри (январь 1994 г.). «Введение в архитектуру программного обеспечения» (PDF) . Достижения в области программной инженерии и инженерии знаний . 1. Архивировано (PDF) из оригинала 6 мая 2021 г. Получено 8 августа 2016 г. – через CMU School of Computer Science.
  37. ^ Парнас, Д. Л. (1972). «О критериях, используемых при разложении систем на модули». Сообщения ACM . 15 (12): 1053–1058. doi : 10.1145/361598.361623 . S2CID 53856438 . 
  38. ^ Майерс, Брэд А.; Стайлос, Джеффри (2016). «Улучшение удобства использования API». Сообщения ACM . 59 (6): 62–69. doi : 10.1145/2896587 . S2CID 543853 . 
  39. ^ Брайан Эллис, Джеффри Стайлос и Брэд Майерс. 2007. «Шаблон фабрики в проектировании API: оценка удобства использования. Архивировано 21 марта 2022 г. на Wayback Machine ». В трудах 29-й международной конференции по программной инженерии ( ICSE '07 ). IEEE Computer Society, США, 302–312. doi :10.1109/ICSE.2007.85.
  40. ^ «Синхронная и асинхронная запись — Packaged Contact Center Enterprise» — Cisco DevNet. Архивировано 03.08.2022 на Wayback Machine .
  41. ^ Сильва, Пауло (2019). "Глобальный рынок облачных микросервисов (с 2021 по 2026 год)". Архивировано из оригинала 2020-02-18 . Получено 2022-03-29 .
  42. ^ "Web Security". 2022-02-18. Архивировано из оригинала 2022-04-02 . Получено 2022-03-29 .
  43. ^ "API Keys – Что такое API Key? | Блог APILayer". 2022-03-01. Архивировано из оригинала 2022-05-16 . Получено 2022-07-15 .
  44. ^ de Ternay, Guerric (10 октября 2015 г.). «Бизнес-экосистема: создание экономического рва». BoostCompanies . Архивировано из оригинала 2016-09-17 . Получено 2016-02-01 .
  45. ^ Бойд, Марк (21.02.2014). «Частный, партнерский или публичный: какая стратегия API лучше всего подходит для бизнеса?». ProgrammableWeb . Архивировано из оригинала 18.07.2016 . Получено 2 августа 2016 г.
  46. ^ Weissbrot, Alison (7 июля 2016 г.). «API-интерфейсы автосервисов повсюду, но что в них для приложений-партнеров?». AdExchanger . Архивировано из оригинала 28 июля 2020 г. Получено 14 августа 2020 г.
  47. ^ "Cloudflare API v4 Documentation". cloudflare . 25 февраля 2020 г. Архивировано из оригинала 26 февраля 2020 г. Получено 27 февраля 2020 г.
  48. ^ Лью, Зелл (17 января 2018 г.). «API-интерфейсы автомобильных сервисов повсюду, но что в них для приложений-партнеров». Smashing Magazine . Архивировано из оригинала 21 февраля 2020 г. Получено 27 февраля 2020 г.
  49. ^ Ши, Линь; Чжун, Хао; Сье, Тао; Ли, Миншу (2011). «Эмпирическое исследование эволюции документации API». Фундаментальные подходы к программной инженерии. Международная конференция по фундаментальным подходам к программной инженерии. Конспект лекций по информатике. Том 6603. С. 416–431. doi : 10.1007/978-3-642-19811-3_29 . ISBN 978-3-642-19810-6. Получено 22 июля 2016 г.
  50. ^ "guava-libraries – Guava: Google Core Libraries для Java 1.6+". Google Project Hosting . 2014-02-04. Архивировано из оригинала 26 марта 2014 г. Получено 2014-02-11 .
  51. ^ Oracle. "How and When to Deprecate APIs". Документация Java SE . Архивировано из оригинала 9 апреля 2016 г. Получено 2 августа 2016 г.
  52. ^ Таканаши, Дин (19 февраля 2020 г.). «Akamai: Киберпреступники атакуют API в компаниях финансовых услуг». Venture Beat . Архивировано из оригинала 27 февраля 2020 г. Получено 27 февраля 2020 г.
  53. ^ Декель, Ури; Хербслеб, Джеймс Д. (май 2009 г.). «Улучшение удобства использования документации API с помощью распространения знаний». Институт исследований программного обеспечения, Школа компьютерных наук . CiteSeerX 10.1.1.446.4214 . 
  54. ^ Парнин, Крис; Треуде, Кристоф (май 2011 г.). «Измерение документации API в Интернете». Web2SE '11: Труды 2-го Международного семинара по Web 2.0 для разработки программного обеспечения . стр. 25–30. doi :10.1145/1984701.1984706. ISBN 9781450305952. S2CID  17751901.
  55. ^ Maalej, Waleed; Robillard, Martin P. (апрель 2012 г.). "Patterns of Knowledge in API Reference Documentation" (PDF) . IEEE Transactions on Software Engineering . Архивировано (PDF) из оригинала 22 августа 2016 г. . Получено 22 июля 2016 г. .
  56. ^ "Структура документа OpenAPI". Документация OpenAPI . Архивировано из оригинала 2022-11-06 . Получено 2022-11-06 .
  57. ^ "Аннотации". Sun Microsystems . Архивировано из оригинала 2011-09-25 . Получено 2011-09-30 ..
  58. ^ "Oracle и конец программирования, каким мы его знаем". DrDobbs. 2012-05-01. Архивировано из оригинала 2012-05-09 . Получено 2012-05-09 .
  59. ^ «API не могут быть защищены авторским правом, утверждает судья в деле Oracle». TGDaily. 2012-06-01. Архивировано из оригинала 2012-12-21 . Получено 2012-12-06 .
  60. ^ "Oracle America, Inc. против Google Inc." (PDF) . Wired . 2012-05-31. Архивировано (PDF) из оригинала 2013-11-04 . Получено 2013-09-22 .
  61. ^ "Oracle Am., Inc. против Google Inc., № 13-1021, Fed. Cir. 2014". Архивировано из оригинала 2014-10-10.
  62. ^ Розенблатт, Сет (9 мая 2014 г.). «Суд встал на сторону Oracle в апелляции по патенту Android на Java». CNET . Архивировано из оригинала 2017-04-19 . Получено 2014-05-10 .
  63. ^ "Google превосходит Oracle – Android «честно использует» API Java". Ars Technica . 2016-05-26. Архивировано из оригинала 2017-01-20 . Получено 28-07-2016 .
  64. ^ Деккер, Сьюзан (27 марта 2018 г.). «Oracle выигрывает возрождение дела на миллиард долларов против Google». Bloomberg Businessweek . Архивировано из оригинала 9 января 2022 г. Получено 27 марта 2018 г.
  65. ^ Ли, Тимоти (25 января 2019 г.). «Google просит Верховный суд отменить катастрофическое решение об авторских правах API». Ars Technica . Архивировано из оригинала 23 апреля 2019 г. Получено 8 февраля 2019 г.
  66. ^ vkimber (28.09.2020). "Google LLC против Oracle America, Inc". LII / Институт юридической информации . Архивировано из оригинала 15.04.2021 . Получено 06.03.2021 .
  67. ^ «Верховный суд Соединенных Штатов, № 18–956, GOOGLE LLC, PETITIONER против ORACLE AMERICA, INC» (PDF) . 5 апреля 2021 г. Архивировано (PDF) из оригинала 5 апреля 2021 г. . Получено 25 апреля 2021 г. .

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

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