stringtranslate.com

API

Скриншот документации по веб-API, написанной НАСА.

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

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

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

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

Цель

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

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

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

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

1940-е и 50-е годы

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

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

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

1960-е и 70-е годы

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

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

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

1990-е годы

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

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

2000-е

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

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

Применение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удаленные API

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

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

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

Веб-API

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

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

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

Дизайн

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

Синхронное и асинхронное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спор по поводу защиты авторских прав на API

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

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

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

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

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

Примеры

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

Рекомендации

  1. ^ Редди, Мартин (2011). Проектирование API для C++. Эльзевир Наука. п. 1. ISBN 9780123850041.
  2. ↑ Аб Лейн, Кин (10 октября 2019 г.). «Введение в API: история API». Почтальон . Проверено 18 сентября 2020 г. Когда вы слышите аббревиатуру «API» или его расширенную версию «Интерфейс прикладного программирования», это почти всегда относится к нашему современному подходу, заключающемуся в том, что мы используем HTTP для предоставления доступа к машиночитаемым данным в формате JSON или XML, часто просто называемые «веб-API». API существуют почти так же давно, как компьютеры, но современные веб-API начали формироваться в начале 2000-х годов.
  3. ^ Вуд, Лаура (25 августа 2021 г.). «Глобальный рынок облачных микросервисов (2021–2026 гг.)». businesswire.com . Проверено 29 марта 2022 г.
  4. ^ abc Кларк, Стивен (2004). «Измерение удобства использования API». Доктор Добб . Проверено 29 июля 2016 г.
  5. ^ ab Архитектура баз данных - технико-экономическое обоснование (Отчет). Вашингтон, округ Колумбия: Министерство торговли США, Национальное бюро стандартов. Апрель 1981 г., стр. 45–47. hdl :2027/mdp.39015077587742. LCCN  81600004. Специальная публикация NBS 500-76 . Проверено 18 сентября 2020 г.
  6. ↑ abcd Блох, Джошуа (8 августа 2018 г.). Краткая и объективная история API (выступление). ККон. Сан-Франциско: InfoQ . Проверено 18 сентября 2020 г.
  7. ^ аб Коттон, Ира В.; Грейторекс, Фрэнк С. (декабрь 1968 г.). «Структуры данных и методы удаленной компьютерной графики». AFIPS '68: Материалы осенней объединенной компьютерной конференции, состоявшейся 9–11 декабря 1968 г. . Осенняя объединенная компьютерная конференция AFIPS 1968 года. Том. I. Сан-Франциско, Калифорния: Ассоциация вычислительной техники. стр. 533–544. дои : 10.1145/1476589.1476661. ISBN 978-1450378994. ОСЛК  1175621908.
  8. ^ «Интерфейс прикладной программы» . Оксфордский словарь английского языка (онлайн-изд.). Издательство Оксфордского университета . (Требуется подписка или членство участвующей организации.)
  9. ^ Дата, CJ (2019). Э. Ф. Кодд и реляционная теория: подробный обзор и анализ основных работ Кодда по базам данных. Лулу.com. п. 135. ИСБН 978-1684705276.
  10. ^ Дата, CJ; Кодд, Э.Ф. (январь 1975 г.). «Реляционный и сетевой подходы: сравнение интерфейсов прикладного программирования». В Рэндалле Растине (ред.). Материалы семинара ACM-SIGMOD 1974 года по описанию данных, доступу и контролю . Семинар SIGMOD, 1974 г. Том. 2. Анн-Арбор, Мичиган: Ассоциация вычислительной техники. стр. 83–113. дои : 10.1145/800297.811532. ISBN 978-1450374187. OCLC  1175623233.
  11. ^ Карл, Маламуд (1990). Анализ сетей Novell. Ван Ностранд Рейнхольд. п. 294. ИСБН 978-0442003647.
  12. ^ Аб Джин, Бренда; Сахни, Саураб; Шват, Амир (2018). Проектирование веб-API. О'Рейли Медиа. ISBN 9781492026877.
  13. ^ Филдинг, Рой (2000). Архитектурные стили и проектирование сетевых архитектур программного обеспечения (доктор философии). Калифорнийский университет в Ирвайне . Проверено 18 сентября 2020 г.
  14. ^ Доцика, Фефи (август 2010 г.). «Семантические API: переход к семантической сети». Международный журнал информационного менеджмента . 30 (4): 335–342. doi :10.1016/j.ijinfomgt.2009.12.003.
  15. ^ Одерский, Мартин; Ложка, Лекс; Веннерс, Билл (10 декабря 2008 г.). «Объединение Scala и Java». artima.com . Проверено 29 июля 2016 г.
  16. ^ де Фигейредо, Луис Энрике; Иерусалимский, Роберто ; Фильо, Вальдемар Селес (1994). «Разработка и реализация языка расширения приложений». TeCGraf Grupo de Tecnologia Em Computacao Grafica : 273–284. CiteSeerX 10.1.1.47.5194 . S2CID  59833827 . Проверено 29 июля 2016 г. 
  17. ↑ Синтес, Тони (13 июля 2001 г.). «Что такое Java API?». JavaWorld . Проверено 18 июля 2020 г.
  18. ^ Уинтерс, Титус; Том Мэншрек; Хайрам Райт, ред. (2020). Разработка программного обеспечения в Google: уроки, извлеченные из программирования с течением времени . Севастополь, Калифорния: O'Reilly Media. ISBN 9781492082798. OCLC  1144086840.
  19. ^ Мастранжело, Луис; Понзанелли, Лука; Моччи, Андреа; Ланца, Мишель; Хаусвирт, Матиас; Нистром, Натаниэль (23 октября 2015 г.). «Используйте на свой страх и риск: небезопасный API Java в дикой природе». Материалы Международной конференции ACM SIGPLAN 2015 г. по объектно-ориентированному программированию, системам, языкам и приложениям . OOPSLA 2015. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 695–710. дои : 10.1145/2814270.2814313. ISBN 978-1-4503-3689-5.
  20. ^ "F2PY.org". F2PY.org . Проверено 18 декабря 2011 г.
  21. ^ Фаулер, Мартин. "Инверсия контроля".
  22. ^ Фаяд, Мохамед. «Среды объектно-ориентированных приложений».
  23. ^ Левин, Дональд А. (1991). Руководство программиста POSIX. O'Reilly & Associates, Inc. с. 1. ISBN 9780937175736. Проверено 2 августа 2016 г.
  24. ^ Уэст, Джоэл; Дедрик, Джейсон (2001). «Стандартизация открытого исходного кода: рост Linux в эпоху сетей» (PDF) . Знания, технологии и политика . 14 (2): 88–112. дои : 10.1007/PL00022278. S2CID  46082812 . Проверено 2 августа 2016 г.
  25. ^ Microsoft (октябрь 2001 г.). «Поддержка Windows XP». Майкрософт. п. 4. Архивировано из оригинала 26 сентября 2009 г.
  26. ^ "Введение LSB" . Фонд Linux. 21 июня 2012 г. Архивировано из оригинала 02 апреля 2015 г. Проверено 27 марта 2015 г.
  27. ^ Стоутон, Ник (апрель 2005 г.). «Обновление стандартов» (PDF) . УСЕНИКС . Проверено 4 июня 2009 г.
  28. ↑ Бирхофф, Кевин (23 апреля 2009 г.). Соответствие протокола API в объектно-ориентированном программном обеспечении (PDF) (доктор философии). Университет Карнеги Меллон. ISBN 978-1-109-31660-5. ПроКвест  304864018 . Проверено 29 июля 2016 г.
  29. ^ Уилсон, М. Джефф (10 ноября 2000 г.). «Будьте умны с прокси и RMI». JavaWorld . Проверено 18 июля 2020 г.
  30. ^ Хеннинг, Мичи; Виноски, Стив (1999). Продвинутое программирование CORBA на C++ . Аддисон-Уэсли . ISBN 978-0201379273. Проверено 16 июня 2015 г.
  31. ^ Бенслиман, Джамал; Шахрам Дустдар; Амит Шет (2008). «Мэшапы сервисов: новое поколение веб-приложений». IEEE Интернет-вычисления, том. 12, нет. 5 . Институт инженеров электротехники и электроники. стр. 13–15. Архивировано из оригинала 28 сентября 2011 г. Проверено 1 октября 2019 г.
  32. ^ Николаи, Джеймс (23 апреля 2008 г.), «Так что же такое корпоративный гибрид?», PC World[ постоянная мертвая ссылка ]
  33. ↑ Парр, Бен (21 мая 2009 г.). «Эволюция API социальных сетей». Машаемый . Проверено 26 июля 2016 г.
  34. ^ «ПОЛУЧИТЕ тенденции/место». разработчик.twitter.com . Проверено 30 апреля 2020 г.
  35. ^ Гарлан, Дэвид; Шоу, Мэри (январь 1994 г.). «Введение в архитектуру программного обеспечения» (PDF) . Достижения в области разработки программного обеспечения и инженерии знаний . 1 . Проверено 8 августа 2016 г.
  36. ^ Парнас, DL (1972). «О критериях разложения систем на модули». Коммуникации АКМ . 15 (12): 1053–1058. дои : 10.1145/361598.361623 . S2CID  53856438.
  37. ^ Майерс, Брэд А.; Стилос, Джеффри (2016). «Улучшение удобства использования API». Коммуникации АКМ . 59 (6): 62–69. дои : 10.1145/2896587. S2CID  543853.
  38. ^ Брайан Эллис, Джеффри Стилос и Брэд Майерс. 2007. Фабричный шаблон в дизайне API: оценка удобства использования. В материалах 29-й международной конференции по программной инженерии ( ICSE '07 ). Компьютерное общество IEEE, США, 302–312. DOI: https://doi.org/10.1109/ICSE.2007.85 http://www.cs.cmu.edu/~NatProg/papers/Ellis2007FactoryUsability.pdf
  39. ^ Синхронная и асинхронная записи — пакетный контакт-центр предприятия — документ — Cisco DevNet
  40. ^ Сильва, Пауло (2019). «Глобальный рынок облачных микросервисов (2021–2026 гг.)» . Проверено 29 марта 2022 г.
  41. ^ «Веб-безопасность». 18 февраля 2022 г. Проверено 29 марта 2022 г.
  42. ^ «Ключи API - Что такое ключ API? | Блог APILayer» . 01.03.2022 . Проверено 15 июля 2022 г.
  43. ↑ де Терне, Геррик (10 октября 2015 г.). «Бизнес-экосистема: создание экономического рва». BoostCompanies . Проверено 1 февраля 2016 г.
  44. ^ Бойд, Марк (21 февраля 2014 г.). «Частный, партнерский или общественный: какая стратегия API лучше для бизнеса?». Программируемая сеть . Проверено 2 августа 2016 г.
  45. ↑ Вайсброт, Элисон (7 июля 2016 г.). «API-интерфейсы автосервиса повсюду, но что это значит для партнерских приложений?». АдExchanger .
  46. ^ «Документация Cloudflare API v4» . облачная вспышка . 25 февраля 2020 г. Проверено 27 февраля 2020 г.
  47. ↑ Лью, Зелл (17 января 2018 г.). «API-интерфейсы автосервисов повсюду, но что в них нужно для партнерских приложений». Разрушительный журнал . Проверено 27 февраля 2020 г.
  48. ^ Ши, Лин; Чжун, Хао; Се, Тао; Ли, Миншу (2011). «Эмпирическое исследование эволюции документации API». Фундаментальные подходы к разработке программного обеспечения. Международная конференция по фундаментальным подходам к программной инженерии. Конспекты лекций по информатике. Том. 6603. стр. 416–431. дои : 10.1007/978-3-642-19811-3_29 . ISBN 978-3-642-19810-6. Проверено 22 июля 2016 г.
  49. ^ «Библиотеки гуавы – Гуава: Основные библиотеки Google для Java 1.6+» . Хостинг проектов Google . 04.02.2014. Архивировано из оригинала 26 марта 2014 года . Проверено 11 февраля 2014 г.
  50. ^ Оракул. «Как и когда отказаться от API». Документация Java SE . Проверено 2 августа 2016 г.
  51. ↑ Таканаши, декан (19 февраля 2020 г.). «Акамай: Киберпреступники атакуют API компаний, предоставляющих финансовые услуги». Венчурный бит . Проверено 27 февраля 2020 г.
  52. ^ Декель, Ури; Хербслеб, Джеймс Д. (май 2009 г.). «Повышение удобства использования документации API за счет распространения знаний». Институт исследований программного обеспечения, Школа компьютерных наук . CiteSeerX 10.1.1.446.4214 . 
  53. ^ Парнин, Крис; Треуде, Кристоф (май 2011 г.). «Документация по измерению API в Интернете». Web2SE '11: Материалы 2-го международного семинара по Web 2.0 для разработки программного обеспечения . стр. 25–30. дои : 10.1145/1984701.1984706. ISBN 9781450305952. S2CID  17751901.
  54. ^ Маалей, Валид; Робиллард, Мартин П. (апрель 2012 г.). «Образцы знаний в справочной документации API» (PDF) . Транзакции IEEE по разработке программного обеспечения . Проверено 22 июля 2016 г.
  55. ^ «Структура документа OpenAPI». Документация OpenAPI . Проверено 6 ноября 2022 г.
  56. ^ «Аннотации». Сан Микросистемс . Архивировано из оригинала 25 сентября 2011 г. Проверено 30 сентября 2011 г..
  57. ^ «Oracle и конец программирования, каким мы его знаем» . Доктор Доббс. 01.05.2012 . Проверено 9 мая 2012 г.
  58. ^ «API не могут быть защищены авторским правом, говорит судья по делу Oracle» . ТГДейли. 01.06.2012 . Проверено 6 декабря 2012 г.
  59. ^ «Oracle America, Inc. против Google Inc.» (PDF) . Проводной . 31 мая 2012 г. Проверено 22 сентября 2013 г.
  60. ^ «Oracle Am., Inc. против Google Inc., № 13-1021, Федеральный округ, 2014 г.» . Архивировано из оригинала 10 октября 2014 г.
  61. ↑ Розенблатт, Сет (9 мая 2014 г.). «Суд встал на сторону Oracle по поводу Android в апелляции по патенту Java» . CNET . Проверено 10 мая 2014 г.
  62. ^ «Google побеждает Oracle – Android «добросовестно использует» API Java» . Арс Техника . 26 мая 2016 г. Проверено 28 июля 2016 г.
  63. ↑ Декер, Сьюзен (27 марта 2018 г.). «Oracle выигрывает возобновление дела против Google на миллиард долларов» . Блумберг Бизнесуик . Проверено 27 марта 2018 г.
  64. ↑ Ли, Тимоти (25 января 2019 г.). «Google просит Верховный суд отменить катастрофическое решение по авторским правам API». Арс Техника . Проверено 8 февраля 2019 г.
  65. ^ Вкимбер (28 сентября 2020 г.). «Google LLC против Oracle America, Inc». ЛИИ/Институт правовой информации . Проверено 06 марта 2021 г.
  66. ^ «Верховный суд США, № 18–956, GOOGLE LLC, ИСТОЧНИК против ORACLE AMERICA, INC» (PDF) . 5 апреля 2021 г.

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

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