API (МФА: [ˌeɪ.piˈaɪ]; аббр. от англ. application programming interface[1], дословно интерфейс программирования приложения) — программный интерфейс, то есть описание способов взаимодействия одной компьютерной программы с другими (в противоположность пользовательскому интерфейсу, используемому для взаимодействия конечного пользователя с программой). Обычно входит в описание какого-либо интернет-протокола (например, SCIM[2]), программного каркаса (фреймворка[3]) или стандарта вызовов функций операционной системы[4]. Часто реализуется отдельной программной библиотекой или сервисом операционной системы. Используется программистами при написании всевозможных приложений.
Проще говоря, это способ взаимодействия какого-то программного кода с набором каких-то программных компонентов, с помощью которых одна компьютерная программа (например, бот или сайт) может использовать другую программу.
Назначение
правитьAPI (интерфейс программирования приложения) упрощает процесс программирования при создании приложений, абстрагируя базовую реализацию и предоставляя только объекты или действия, необходимые разработчику. Если графический интерфейс для почтового клиента может предоставить пользователю кнопку, которая выполнит все шаги для выборки и выделения новых писем, то API для ввода/вывода файлов может дать разработчику функцию, которая копирует файл из одного места в другое, не требуя от разработчика понимания операций файловой системы, происходящих за кулисами[5].
API как средство интеграции приложений
правитьЕсли программу (модуль, библиотеку) рассматривать как чёрный ящик, то API — это набор «ручек», которые доступны пользователю данного ящика и которые он может вертеть и переключать.
Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.
По такому принципу построены протоколы передачи данных по Интернету. Стандартный стек протоколов (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего («нижележащего») уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему («вышележащему») уровню.
Понятие протокола близко по смыслу к понятию API. И то, и другое является абстракцией функциональности, только в первом случае речь идёт о передаче данных, а во втором — о взаимодействии приложений.
API библиотеки функций и классов включает в себя описание сигнатур и семантики функций.
Сигнатура функции
правитьСигнатура функции — часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функций в этих языках.
Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.
Например, в языке программирования C++ простая функция однозначно опознаётся компилятором по своему имени и последовательности типов своих аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет участвовать и имя класса.
В языке программирования Java сигнатуру метода составляют его имя и последовательность типов параметров; тип возвращаемого значения в сигнатуре не участвует[6].
Семантика функции
правитьСемантика функции — это описание того, что данная функция делает. Семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. Обычно результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. Тогда результат функции может зависеть от этого состояния, и, кроме того, результатом может стать изменение состояния. Логика этих зависимостей и изменений относится к семантике функции. Полным описанием семантики функций является исполняемый код функции или математическое определение функции.
API операционных систем. Проблемы, связанные с многообразием API
правитьПрактически все операционные системы (UNIX, Windows, OS X, Linux и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.
В индустрии программного обеспечения общие стандартные API для стандартной функциональности играют важную роль, так как они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайней мере, типичным привычным образом. В случае API графических интерфейсов это означает, что программы будут иметь похожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов.
С другой стороны, различия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов wxWidgets, GTK и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написание интерпретируемых языков, реализуемых на разных платформах (sh, Python, Perl, PHP, Tcl, JavaScript, Ruby и т. д.).
Также в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый API обычно реализован с использованием API программных компонент более низкого уровня абстракции.
Например: для того, чтобы увидеть в браузере строчку «Hello, world!», достаточно лишь создать HTML-документ с минимальным заголовком и простейшим телом, содержащим данную строку. Когда браузер откроет этот документ, программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл и разберётся в его устройстве, затем последовательно вызовет через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать „Hello, world!“ выбранным шрифтом». Во время выполнения этих операций библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы, чтобы записать данные в буфер видеокарты.
При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. К тому же различные браузеры используют различные HTML-библиотеки, и, кроме того, всё это может быть собрано с использованием различных библиотек примитивов и на различных операционных системах.
Основными сложностями существующих многоуровневых систем API, таким образом, являются:
- Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
- Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.
Наиболее известные API
правитьСписок примеров в этой статье не основывается на авторитетных источниках, посвящённых непосредственно предмету статьи. |
- DirectMusic/DirectSound (часть DirectX)
- OpenAL
Web API
правитьИспользуется в веб-разработке — содержит, как правило, определённый набор HTTP-запросов, а также определение структуры HTTP-ответов, для выражения которых чаще всего используют XML− или JSON−формат, а также ProtoBuf, XDR и некоторые другие.
Web API является практически синонимом для веб-службы, хотя в последнее время за счёт тенденции Web 2.0 осуществлён переход от SOAP к REST типу коммуникации. Веб-интерфейсы, обеспечивающие сочетание нескольких сервисов в новых приложениях, известны как гибридные.
См. также
править
Примечания
править- ↑ Переводится как «программный интерфейс приложения», «интерфейс прикладного программирования». Часто употребляется упрощённое транслитерированное сленговое название [апи́]. Используются и укороченные варианты перевода — «интерфейс приложения», «программный интерфейс».
- ↑ System for Cross-Domain Identity Management: Protocol draft-ietf-scim-api-19. Дата обращения: 12 октября 2018. Архивировано 7 июля 2017 года.
- ↑ Spring Framework 5.3.1 API. Дата обращения: 12 октября 2018. Архивировано 10 октября 2018 года.
- ↑ The Linux kernel user-space API guide. Дата обращения: 12 октября 2018. Архивировано 12 октября 2018 года.
- ↑ Clarke, Steven Measuring API Usability. Dr. Dobb's (2004). Дата обращения: 9 июля 2021. Архивировано 3 марта 2022 года.
- ↑ Java Language Specification. Chapter 8.4.2. "Method Signature". Java Language Specification. docs.oracle.com. Дата обращения: 24 февраля 2020. Архивировано 3 мая 2020 года.
В статье не хватает ссылок на источники (см. рекомендации по поиску). |