exam08 4 - stankin/design-part-1 GitHub Wiki
Программные интерфейсы приложений (API)
Реферат к лекции 8. Проектирование программного продукта.
Выполнил: Крючков Павел
Проверила: Парфенова Анастасия
Программные интерфейсы API
Программные интерфейсы API
Интерфе́йс программи́рования приложе́ний (Application Programming Interface, API [эй‐пи‐ай]; по-русски чаще произносят [апи́]) — набор методов (функций), который программист может использовать для доступа к функциональности программного компонента (программы, модуля, библиотеки). API является важной абстракцией, описывающей функциональность «в чистом виде», безотносительно того, как реализована эта функциональность.
API определяет функциональность, которую предоставляет программа (модуль, библиотека), при этом API позволяет абстрагироваться от того, как именно эта функциональность реализована.
Если программу рассматривать как чёрный ящик, то API — это множество «ручек», которые доступны пользователю данного ящика, которые он может вертеть и дёргать.
Программные компоненты взаимодействуют друг с другом посредством API. При этом обычно компоненты образуют иерархию — высокоуровневые компоненты используют API низкоуровневых компонентов, а те, в свою очередь, используют API ещё более низкоуровневых компонентов.
По такому принципу построены протоколы передачи данных по Internet. Стандартный протокол Internet (сетевая модель OSI) содержит 7 уровней (от физического уровня передачи пакетов бит до уровня протоколов приложений, подобных протоколам HTTP и IMAP). Каждый уровень пользуется функциональностью предыдущего уровня передачи данных и, в свою очередь, предоставляет нужную функциональность следующему уровню.
Важно заметить, что понятие протокола близко по смыслу к понятию API. И то и другое является абстракцией функциональности, только в первом случае речь идёт о передаче данных, а во втором — о построении компьютерных приложений.
API библиотеки функций и классов включает в себя описание _сигнатур _и семантики функций.
Application Programming Interface (API) программный интерфейс взаимодействия между системами, позволяющий:
- Получать доступ к бизнес-сервисам предприятия
- Обмениваться информацией между системами и приложениями
- Упростить взаимодействие между компаниями, партнерами, разработчиками и клиентами
Open API стратегия
API стратегия включает в себя:
- Разработку бизнес-продуктов на основе существующих API
- Предоставление внутренних сервисов разработчикам
- Модели монетизации API для построения мультиканального взаимодействия и повышения прибыли
Реализация концепции Open API помогает трансформировать бизнес, встраивать его в гибкую проектную экосистему игроков рынка, создавать условия для постоянной генерации новых идей и формирования дополнительной ценности при управлении массивами корпоративных данных.
Рынок интеграционных решений развивается в контексте эволюции API - от EDI и SOAP до Web 2.0, с которого началась эра публичных API. Число таких интерфейсов в ближайшие 3 года может вырасти более чем в 50 раза и достичь 1 миллиона. Это связано с мультиканальностью: каналы взаимодействия с клиентами должны меняться вместе с ними. Непрерывный рост количества потребителей и объема данных привел к появлению экономики API, помогающей на основе открытых интерфейсов создавать инновационные бизнес-модели использования корпоративных активов и сервисов.
Сигнатура функции
Сигнатура функции — часть общего объявления функции, позволяющая средствам трансляции идентифицировать функцию среди других. В различных языках программирования существуют разные представления о сигнатуре функции, что также тесно связано с возможностями перегрузки функции в этих языках.
Иногда различают сигнатуру вызова и сигнатуру реализации функции. Сигнатура вызова обычно составляется по синтаксической конструкции вызова функции с учётом сигнатуры области видимости данной функции, имени функции, последовательности фактических типов аргументов в вызове и типе результата. В сигнатуре реализации обычно участвуют некоторые элементы из синтаксической конструкции объявления функции: спецификатор области видимости функции, её имя и последовательность формальных типов аргументов.
Например, в языке программирования C++ простая функция однозначно опознаётся компилятором по её имени и последовательности типов её аргументов, что составляет сигнатуру функции в этом языке. Если функция является методом некоторого класса, то в сигнатуре будет учаcтвовать и имя класса.
В языке программирования Java сигнатуру метода составляет его имя и последовательность типов параметров; тип значения в сигнатуре не участвует.
Семантика функции
Семантика функции — это описание того, что данная функция делает. Семантика функции включает в себя описание того, что является результатом вычисления функции, как и от чего этот результат зависит. Обычно результат выполнения зависит только от значений аргументов функции, но в некоторых модулях есть понятие состояния. Тогда результат функции может зависеть от этого состояния, и, кроме того, результатом может стать изменение состояния. Логика этих зависимостей и изменений относится к семантике функции. Полным описанием семантики функций является исполняемый код функции или математическое определение функции.
Основные типы API
Внутренние API
- Доступ к API предоставляется только внутренним разработчикам
- Приложения нацелены на сотрудников предприятия
Бизнес-драйверы:
- Консистентность разработки
- Снижение затрат
- Повышение эффективности разработки
Партнерские API
- API доступны только ограниченному набору бизнес-партнеров
- Приложения предназначены для конечных потребителей и для бизнес-пользователей
Бизнес-драйверы:
- Автоматизация процесса разработки
- Развитие партнерских отношений
- Оптимизация процесса взаимодействия с партнерами
Публичные API
Доступ предоставляется любому внешнему разработчику. Приложения нацелены на конечных пользователей.
Бизнес-драйверы:
- Разработка новых сервисов
- Развитие экосистемы
- Мультиканальное взаимодействие
API для облачного хранения
Интерфейсы прикладного программирования (application programming interfaces, API) для связи облачных хранилищ с приложениями бывают различных типов. На объединении данных из различных онлайн-источников строится огромное количество веб-контента. Когда-то давно эту комбинацию называли «мэшапами» или «Интернет 2.0», но сегодня веб-приложения стало частью современного мира ИТ.
Потенциально существует некоторая двусмысленность в отношении того, что подразумевается под API для хранения данных. Это связано с тем, что в самом общем смысле API — это просто код, который позволяет одной части ПО подключаться к другой. Например, если мы говорим об «API для систем хранения», то это может подразумевать API, предоставляемые производителем массивов хранения для обеспечения мониторинга и управления своими продуктами для ПО, которое пишут разработчики. Можно также упомянуть о веб-интерфейсе разработки localStorage, который позволяет браузерным приложениям сохранять данные локально, и который считается небезопасным. Но вместо этого лучше рассмотреть API, которые предоставляют стороннее хранилище или сервисы хранения данных (базы, озера и хранилища данных), к которым разработчики могут подключаться через API, встроенные в код приложений.
API для хранения данных можно разделить на несколько категорий, включая:
- API, которые подключаются к облачным сервисам синхронизации файлов и облачным дискам, а также к приложениям для повышения продуктивности, таким как Google Workspace или Microsoft 365 через Graph API;
- API для подключения веб-приложений к службам хранения данных облачных провайдеров;
- API, позволяющие использовать сервисы, связанные с хранением данных, такие как базы, озера и хранилища данных.
API операционных систем
- Windows API
- POSIX
- Linux Kernel API
- OS/2 API
- Amiga ROM Kernel
Практически все операционные системы (Unix, Windows, MacOS, и т. д.) имеют API, с помощью которого программисты могут создавать приложения для этой операционной системы. Главный API операционных систем — это множество системных вызовов.
В индустрии программного обеспечения общие стандартные API для стандартной функциональности имеют важную роль, так как они гарантируют, что все программы, использующие общий API, будут работать одинаково хорошо или, по крайне мере, типичным привычным образом. В случае API графических интерфейсов это означает, что программы будут иметь похожий пользовательский интерфейс, что облегчает процесс освоения новых программных продуктов.
С другой стороны, отличия в API различных операционных систем существенно затрудняют перенос приложений между платформами. Существуют различные методы обхода этой сложности — написание «промежуточных» API (API графических интерфейсов Qt, Gtk, и т. п.), написание библиотек, которые отображают системные вызовы одной ОС в системные вызовы другой ОС (такие среды исполнения, как Wine, cygwin, и т. п.), введение стандартов кодирования в языках программирования (например, стандартная библиотека языка C), написания интерпретируемых языков, реализуемых на разных платформах (sh, perl, php, tcl, Java, и т. д.)
Также необходимо отметить, что в распоряжении программиста часто находится несколько различных API, позволяющих добиться одного и того же результата. При этом каждый API обычно реализован с использованием API программных компонент более низкого уровня абстракции.
Например: для того, чтобы увидеть в браузере строчку «Hello, world!» достаточно лишь создать HTML-документ с минимальным заголовком, и простейшим телом, содержащим данную строку. Что произойдёт, когда браузер откроет этот документ? Программа-браузер передаст имя файла (или уже открытый дескриптор файла) библиотеке, обрабатывающей HTML-документы, та, в свою очередь, при помощи API операционной системы прочитает этот файл, и разберётся в его устройстве, повызывает через API библиотеки стандартных графических примитивов операции типа «очистить окошко», «написать выбранным шрифтом Hello, world!», при этих операциях библиотека графических примитивов обратится к библиотеке оконного интерфейса с соответствующими запросами, уже эта библиотека обратится к API операционной системы с запросами вида «а положи-ка мне в буфер видеокарты вот это».
При этом практически на каждом из уровней реально существует несколько возможных альтернативных API. Например: мы могли бы писать исходный документ не на HTML, а на LaTeX, для отображения могли бы использовать любой браузер. Различные браузеры, вообще говоря, используют различные HTML-библиотеки, и, кроме того, всё это может быть (вообще говоря) собрано с использованием различных библиотек примитивов и на различных операционных системах.
Основными сложностями существующих многоуровневых систем API, таким образом, являются:
- Сложность портирования программного кода с одной системы API на другую (например, при смене ОС);
- Потеря функциональности при переходе с более низкого уровня на более высокий. Грубо говоря, каждый «слой» API создаётся для облегчения выполнения некоторого стандартного набора операций. Но при этом реально затрудняется, либо становится принципиально невозможным выполнение некоторых других операций, которые предоставляет более низкий уровень API.
API баз данных
Существуют две основные классификации – внутрипроцессные/внепроцессные API и SQL/NoSQL.
Внутрипроцессные vs внепроцессные интерфейсы
Если БД (по крайней мере, частично) работает внутри клиентского процесса, то ее интерфейс называется внутрипроцессным (in-process API). В этом случае последний располагает библиотекой функций, которые вызывают методы напрямую в процессоре базы данных. Такой механизм снижает время ожидания до минимума и увеличивает пропускную способность до максимума (то есть по максимуму использует предоставленную память). Однако при внутрипроцессном подходе только одно клиентское приложение единовременно имеет доступ к БД, так что API теряет очки в гибкости. Кроме того, подход связан с дополнительным риском: если клиентское приложение зависает или дает сбой, то же происходит со всей БД – ведь они делят один процесс на двоих.
Если же БД работает в отдельном процессе (в этом случае мы говорим о внепроцессном API (out-of-process API), то для доступа к ней обычно используется протокол, основанный на TCP/IP. Многие СУРБД (системы управления реляционными базами данных) – в последнее время и другие виды БД – поддерживают либо ODBC (open database connectivity, открытый механизм взаимодействия с БД), либо JDBC (java database connectivity, соединение с БД на Java). Это упрощает создание клиентских приложений – существует более чем достаточно библиотек, использующих две вышеуказанных технологии. Использование сетевого протокола позволяет значительно увеличить гибкость базы данных (точнее, доступа к ней), но TCP проигрывает по сравнению с прямым доступом в отношении показателей использования памяти и времени ожидания системы.
SQL vs NoSQL
SQL – это декларативный язык, первоначально разработанный для того, чтобы упростить хранение и извлечение данных из реляционных БД. Сегодня его используют повсеместно – поэтому неудивительно, что большинство разработчиков «говорит» на SQL весьма бегло – и это несомненный плюс для внедрения любой БД.
Что касается NoSQL, то самой значительной «инновацией» этого подхода является повышение скорости операций за счет устранения транзакций и реляционных таблиц. Многие из NoSQL баз данных, как ни парадоксально, поддерживают SQL как язык прикладных интерфейсов, хотя изначально не пользовались его реляционными «фишками» — а вот запросы, фильтры и функции агрегации оказались весьма полезны. Отсюда и взялась идея о том, что логичнее было бы переименовать технологию в NoACID (атомарность, последовательность, отделение, сохраняемость) – ведь она не противоречит сути SQL, а просто не поддерживает транзакции. В 2014 году все те же NoSQL БД стали поддерживать и транзакции, поэтому более точным названием для технологии могло бы быть выражение NoRelational – однако закрепившееся за ней и более-менее точное NoSQL так и осталось.
Одна из главных проблем, связанных с использованием SQL, состоит в том, что перед использованием данные должны быть разделены на составные части и скомпилированы процессором БД – а это, естественно, чревато задержками. Большинство процессоров БД и клиентских API решают эту проблему при помощи прекомпиляции или компиляции во время первого прогона, соответственно, функции на базе SQL обращаются к вновь сформированным таблицам. Скомпилированная версия затем сохраняется и используется для будущих обращений.
Еще одна проблема состоит в том, что SQL не может корректно и эффективно описать все виды связей внутри данных – к примеру, это касается иерархической структуры. И еще: в исходной спецификации SQL как декларативного языка не описаны такие крайне важные операции как итерация. В конечном итоге спецификацию пришлось расширить – и современный SQL поддерживает рекурсию, что позволяет работать с итерацией и иерархическими структурами. Кроме того, вендоры добавляют языку собственные нестандартные расширения. Впрочем, эти расширения поддерживаются не везде – и точно так же далеко не все знают, как их применять. Вообще говоря, очень многие базы данных вообще не требуют индексации и агрегации – и тогда причин использовать SQL с его сложными механизмами работы с данными практически не остается. Яркий пример – большинство хранилищ, организованных по принципу «ключ-значение».