Что такое API (простыми словами)

Слова «программный интерфейс» или API слышал каждый, кто сталкивался с процессом разработки/запуска современных сайтов, web-сервисов и даже приложений.

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

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

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

Что такое API

API (аббревиатура от Application Programming Interface, «программный интерфейс приложения») – это специальный интерфейс (набор команд/элементов управления), который предназначен для взаимодействия разных программ между собой.

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

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

Примеры использования API

На самом деле вокруг нас очень много программных продуктов, у которых есть API. Приведём наиболее яркие примеры.

Погодные приложения/виджеты

Погодные приложения/виджеты

Когда вы открываете любой маркет мобильных приложений и ищите там удобный виджет для отображения погоды, вы можете обнаружить тысячи разных вариантов. Хотя на самом деле источником данных для отображения погодных сведений выступают всего 5-10 популярных сервисов, таких как weather.com, Gismetio и т.п. Они предоставляют официальный API, которым пользуются разработчики всех этих приложений/виджетов. Разработчики только реализуют внешнюю часть – оформление/фронтэнд.

Онлайн-карты

Онлайн-карты

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

Всё это происходит благодаря работе со слоями и метками через API карт. Карты можно легко встроить в любой сайт, web-страничку, мобильное приложение. Готовые модули есть практически в любом онлайн-конструкторе.

Приложения для операционных систем

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

Причём этот принцип одинаков как для Windows-систем, так и для Linux-дистрибутивов, программных продуктов Apple, для Android-систем и т.п.

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

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

Плагины/модули для CMS-систем

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

А вот наличие открытого API для облачных конструкторов – это уже большая редкость. Здесь API применяется тоже в основном для создания расширений, только необходимую инфраструктуру для этого предоставляют лишь немногие игроки рынка. Например, API есть у uCoz и у Wix. Больше подробностей в наших обзорах онлайн-конструкторов.

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

Второй момент – API для управления внешними интерфейсами. Модель API-First, применяется в первую очередь в Headless CMS. Но многие популярные движки уже реализовали аналогичный подход, например, API для подключения мобильных или web-приложений есть в WordPress, Drupal и Joomla. Больше информации можно узнать в других наших обзорах по CMS-системам.

Виды и форматы web-API

По подходам к проектированию архитектуры сетевых приложений часто выделяют следующие методологии:

REST

Сокращение от REpresentational State Transfer, то есть «передача репрезентативного (самоописываемого) состояния». Это один из наиболее популярных архитектурных стилей для проектирования распределённых web-приложений и сервисов. Концепция REST была представлена Р. Филдингом в 2000 году и предполагала ряд определённых свойств и ограничений (обязательная клиент-серверная модель, состояния клиентов не хранятся на сервере, кэшированные данные должны специально обозначаться, интерфейсы должны быть унифицированы, в системе может быть несколько слоёв, но они должны иметь иерархическую структуру, исполняемый код предоставляется клиентам в исключительных случаев, например, для JavaScript-тегов). Если принципы вашего API не нарушают шесть обязательных ограничений по Филдингу, то интерфейс можно назвать RESTful.

Преимущества:

  • Системы на принципах REST хорошо масштабируются (благодаря нескольким слоям и применению балансировщиков).
  • Они имеют высокую производительность (состояние клиентов не отслеживается, все запросы самодостаточные, можно задействовать готовые системы кэширования).
  • Легко добавлять новые компоненты и редактировать имеющиеся (интерфейсы могут «эволюционировать» вместе с вашим приложением/сервисом).
  • Данные передаются между приложениями напрямую, без необходимости применения прослоек и обёрток.

Недостатки:

  • Получаемые данные часто бывают избыточными. Соответственно, растёт объём передаваемой информации и требуется дополнительная работа для осуществления выборки нужной.
  • Структура ответов жёстко определяется сервером. Только так, и никак иначе.
  • Сложности при отладке, так как ошибка при обмене данными может возникать в разных точках прохождения запроса.
  • Сильная привязка к протоколу HTTP.
  • Нет чётких стандартов/спецификаций, только принципы.

SOAP

Изначально акроним образовывался от сокращения слов Simple Object Access Protocol, «простой протокол доступа к объектам». Но в последней версии протокола акроним уже никак не расшифровывается. Методология появилась в 1998 году, как расширение XML-RPC, но позже подход стал самостоятельным. Основные отличия от REST – нацеленность на веб-службы и использование структурированных сообщений (со специальной разметкой).

Преимущества:

  • SOAP абсолютно нейтрален. Он может работать поверх любых существующих интернет-протоколов (HTTP, SMTP, FTP и т.д.).
  • SOAP не привязывается к HTTP-ответам. Легко коммутируется и туннелируется по любым доступным каналам связи.
  • Данные хорошо структурированы, поэтому поиск и чтение нужной информации существенно упрощено. Текстовые данные легко переводить на разные языки.
  • Обработка и отладка ошибок хорошо стандартизирована. Вообще весь стандарт имеет чёткие спецификации, в отличии от «общих» принципов REST.

Недостатки:

  • Часть важных функций, которые реализуются за счёт HTTP-протокола нужно реализовывать отдельно: кэширование и масштабирование на уровне сервера, анализ кодов ответов (они вообще никак не привязываются к HTTP-запросам).
  • Полученные данные нужно «распарсить», то есть прочитать и на основе имеющейся разметки, преобразовать в наборы раздельных данных (обязательно нужен специальный модуль парсинга, а значит повышается уровень потребления ресурсов для обсчётов).

В качестве более конкретной реализации, достаточно популярной в web-разработке, стоит упомянуть:

GraphQL

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

Преимущества:

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

Недостатки:

  • Тяжелее задействовать систему HTTP-кэширования.
  • Использование GraphQL может усложнить определённые типы задач.
  • При неправильной проработке архитектуры запросов, может существенно увеличиться нагрузка на ваш сервер.
  • Схемы GraphQL не рассчитаны на динамические функции.

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

  • XML,
  • YAML,
  • JSON,
  • И др.

С точки зрения типа доступа к данным, API бывают закрытыми (то есть без доступа во внешние системы) и публичными/открытыми (интерфейсы с доступом из внешних сетей).

API и безопасность

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

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

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

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

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

Преимущества использования API для разработчиков

  • Гораздо проще масштабировать сервис или приложение для работы с большими нагрузками.
  • С помощью API можно обмениваться данными как с внешними приложениями, так и с внутренними (плагины, расширения, комплексные модули и т.п.).
  • Разработку над крупным проектом можно вести параллельно несколькими командами, у каждой из которых будет своя платформа и инструменты (язык программирования, фреймворки и т.п.).
  • Высокая стабильность (легко перезапустить или остановить отдельные модули, остальные просто продолжат работу).
  • Можно чётко разграничить бизнес-логику, базы данных и интерфейсы. В качестве фронтенда можно использовать: web-страницы, мобильные или универсальные приложения, интерфейсы IoT и т.д.
  • API могут эволюционировать вместе с вашим продуктом.

Общие недостатки API

  • Высокие трудовые затраты на реализацию.
  • Сложная архитектура сервиса/приложения.
  • Ключевые наборы данных для API основных модулей нужно разработать самыми первыми (ещё когда нет самих модулей). Крупные логические ошибки на этом этапе будет очень сложно исправить в будущем.
  • Открытые (публичные) API нужно хорошо защищать от злоумышленников.
  • Для небольших проектов свойственно излишнее потребление ресурсов сервера (в сравнении с тем же «монолитом»).
  • Слабое предложение готовых реализаций. API есть только в наиболее продвинутых/популярных CMS-системах (+во фреймворках).
  • В любом случае, API – это инструмент для профессионалов.

Выводы

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

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

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

» Статьи » Что такое API (простыми словами)