API

Материал из wikixw
Перейти к навигации Перейти к поиску

API (Application Programming Interface) — набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) или операционной системой для использования во внешних программных продуктах. В CPA используется, например, для интеграции интерфейса партнерской программы с CRM и КЦ рекламодателя.

"Api.php" перенаправляет сюда. Для API Википедии см. Специальный раздел:ApiHelp. Для других целей см. раздел API (устранение неоднозначности).

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

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

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

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

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

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

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

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

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

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

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

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

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

Термин "прикладной программный интерфейс" (без -ки - суффикс) впервые зафиксирован в документе, называемые структуры данных и методов дистанционного компьютерной графики представлены на Афипс конференции в 1968 году. в данной работе авторы используют этот термин для описания взаимодействия приложений в графическом редакторе, в данном случае—с остальной компьютерной системой. Согласованный интерфейс приложения (состоящий из вызовов подпрограмм Fortran) был предназначен для того, чтобы освободить программиста от работы с особенностями устройства отображения графики и обеспечитьаппаратная независимость, если компьютер или дисплей были заменены.

Термин был введен в область баз данных C. J. Date[8] в статье 1974 года под названием "Реляционный и сетевой подходы: сравнение интерфейса прикладного программирования". API стал частью платформы ANSI/SPARC для систем управления базами данных. Эта структура рассматривала интерфейс прикладного программирования отдельно от других интерфейсов, таких как интерфейс запросов. Специалисты по базам данных в 1970-х годах заметили, что эти различные интерфейсы могут быть объединены; достаточно богатый интерфейс приложения также может поддерживать другие интерфейсы.

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

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

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

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

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

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

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

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

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

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

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

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

Использование API может варьироваться в зависимости от типа используемого языка программирования. API для процедурный язык , такой как Lua В может состоять в основном из рутинных действий, для выполнения кода, обработки данных и обрабатывать ошибки, в то время как API-интерфейс для объектно-ориентированный язык, такой как Java, обеспечит спецификация классы и методы классов. Хайрам закона отмечается, что "достаточное количество пользователей в API, это не имеет значения, что вам обещают в договоре: все наблюдаемое поведение системы будет зависеть от кого-то."Между тем, несколько исследований показывают, что большинство приложений, использующих API, как правило, используют небольшую часть API. Использование API на самом деле варьируется в зависимости от количества пользователей, а также от популярности API.

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

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

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

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

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

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

Дистрибутив программного обеспечения Linux и Berkeley являются примерами операционных систем, реализующих API POSIX.

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

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

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

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

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

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

Веб-интерфейсы API[править]

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

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

При использовании в контексте веб-разработки API обычно определяется как набор спецификаций, таких как сообщения запроса протокола передачи гипертекста (HTTP), наряду с определением структуры сообщений ответа, обычно в расширяемом языке разметки (XML) или формате обозначения объектов JavaScript (JSON). Примером может служить API транспортной компании, который можно добавить на веб-сайт, ориентированный на электронную коммерцию, для облегчения заказа услуг доставки и автоматического включения текущих тарифов на доставку, без необходимости разработчику сайта вводить таблицу тарифов отправителя в веб-базу данных. В то время как "веб-API" исторически был практически синонимом веб-сервиса, недавняя тенденция (так называемая Веб 2.0) заключалась в переходе от веб-сервисов на основе протокола простого доступа к объектам (SOAP) и сервис-ориентированной архитектуры (SOA) к более прямым веб-ресурсам в стиле передачи состояния (REST). и ресурсно-ориентированная архитектура (ROA). Часть этой тенденции связана с движением семантической сети к Структуре описания ресурсов (RDF), концепции продвижения технологий разработки онтологий на основе Интернета. Веб-API позволяют комбинировать несколько API в новых приложениях, известных как мэшапы. В пространстве социальных сетей веб-API позволяют веб-сообществам облегчать обмен контентом и данными между сообществами и приложениями. Таким образом, контент, созданный в одном месте динамически, может быть размещен и обновлен в нескольких местах в Интернете. Например, API REST Twitter позволяет разработчикам получать доступ к основным данным Twitter, а API поиска предоставляет разработчикам методы взаимодействия с данными поиска и тенденций в Twitter.

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

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

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

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

Основными политиками для выпуска API являются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Согласиться с утверждением Oracle означало бы разрешить любому авторскому праву одну версию кода для выполнения системы команд и тем самым запретить всем остальным писать разные версии для выполнения всех или части одних и тех же команд.

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

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

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

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

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

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

Читать[править]

computationalculture.net/objects-of-intense-feeling-the-case-of-the-twitter-api/

Пруф[править]

forrester.com/what-it-means/ep218-google-oracle-api-case/

Источник — https://wikixw.ru/index.php?title=API&oldid=30059