✖
~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ 6E351801C832A3C5D53CE453728F665F__1718584920 ✰
Заголовок документа оригинал.:
✰ API - Wikipedia ✰
Заголовок документа перевод.:
✰ API — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/Application_Programming_Interface ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/6e/5f/6e351801c832a3c5d53ce453728f665f.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/6e/5f/6e351801c832a3c5d53ce453728f665f__translat.html ✰
Дата и время сохранения документа:
✰ 21.06.2024 12:47:03 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 17 June 2024, at 03:42 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.) 
✰ https://arc.ask3.ru ✰
 Ответы на вопросы (Сервис ответов на вопросы, в основном, научной направленности) 
✰ https://ask3.ru/answer2question ✰
 Товарный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collation ✰
 Партнеры 
✰ https://comrades.ask3.ru ✰


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

API — Википедия Jump to content

API

Из Википедии, бесплатной энциклопедии
Чтобы узнать о других значениях, см. API (значения) .
«Api.php» перенаправляется сюда. Информацию об API Википедии см. в разделе Special:ApiHelp .
Снимок экрана документации веб-API , написанной НАСА и демонстрирующей использование 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-е и 50-е годы [ править ]

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

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

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

1960-е и 70-е годы [ править ]

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

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

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

1990-е годы [ править ]

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

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

2000-е [ править ]

Роя Филдинга В диссертации «Архитектурные стили и проектирование сетевых программных архитектур» в Калифорнийском университете в Ирвине в 2000 году была изложена передача репрезентативного состояния (REST) ​​и описана идея «сетевого интерфейса прикладного программирования», который Филдинг противопоставил традиционному «библиотечному интерфейсу». на основе» API. [14] Веб-API XML и JSON получили широкое коммерческое распространение, начиная с 2000 года и продолжаясь с 2022 года. Веб-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 предоставляет ABI. [27] [28]

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

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

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

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

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

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

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

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

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

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

Дизайн API оказывает существенное влияние на его использование. [5] Прежде всего, проектирование программных интерфейсов представляет собой важную часть архитектуры программного обеспечения , организации сложной части программного обеспечения. [36] Принцип сокрытия информации описывает роль программных интерфейсов как возможность модульного программирования путем сокрытия деталей реализации модулей, чтобы пользователям модулей не приходилось понимать сложности внутри модулей. [37] Помимо предыдущего основного принципа, другие показатели измерения удобства использования API могут включать такие свойства, как функциональная эффективность, общая правильность и обучаемость для новичков. [38] Один простой и широко распространенный способ разработки API — следовать Nielsen по эвристической рекомендациям оценке. Шаблон фабричного метода также типичен при разработке 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. Например, компании по прокату автомобилей, такие как Uber и Lyft, позволяют одобренным сторонним разработчикам напрямую заказывать поездки из своих приложений. Это позволяет компаниям осуществлять контроль качества, определяя, какие приложения имеют доступ к API, и обеспечивает им дополнительный источник дохода. [46]
  • Публичный : API доступен для публичного использования. Например, Microsoft делает общедоступным API Windows , а Apple выпускает свой API Cocoa , чтобы можно было писать программное обеспечение для их платформ . Не все общедоступные API доступны всем. Например, поставщики интернет-услуг, такие как Cloudflare или Voxility, используют API-интерфейсы RESTful, чтобы предоставить клиентам и реселлерам доступ к информации об их инфраструктуре, статистике DDoS, производительности сети или элементам управления информационной панели. [47] Доступ к таким API предоставляется либо с помощью «токенов API», либо посредством проверки статуса клиента. [48]

Последствия публичного 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. [55]

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

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

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

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

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

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

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

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

Основная категория: Интерфейсы прикладного программирования

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

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

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

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

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=API&oldid=1229494899"
Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: 6E351801C832A3C5D53CE453728F665F__1718584920
URL1:https://en.wikipedia.org/wiki/Application_Programming_Interface
Заголовок, (Title) документа по адресу, URL1:
API - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)