Типы API и в чём их отличия

Пять типов веб-API по области использования

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

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

В веб-сервисах обычно используются следующие типы API:

• Внешние API открывают доступ для всех, кто соблюдает требования, без тщательной проверки личности пользователя или варианта использования. Могут требовать согласия с условиями применения или налагать ограничение на скорость запросов бесплатных учётных записей. Многие из них просят регистрации и аутентификации, но часто это делается с помощью легкодоступного ключа. К этой категории можно отнести Google Maps или API-схемы оценки гигиены пищевых продуктов, предоставленные правительством Великобритании. Поскольку вся информация здесь общедоступна, нет необходимости требовать авторизацию.
• Партнёрский API доступен только специально отобранным и авторизованным сторонним разработчикам или потребителям для облегчения взаимодействия между компаниями. Например, МТС Exolve предлагает такие инструменты, когда компании хотят внедрить коммуникационные цепочки и выборочно обмениваться данными о клиентах с CRM.
• Внутренний или частный API предназначен только для использования внутри предприятия для подключения систем и данных в рамках бизнеса. Он может использоваться, например, для соединения платёжной ведомости организации и системы управления персоналом.
• Составные или комбинированные API обычно объединяют два или более типа API для создания последовательности взаимозависимых операций и будут полезны для решения сложных или тесно связанных функций API.

Типы API по архитектурным подходам

Монолитные API

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

API микросервисов

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

Составные API

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

Унифицированные API

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

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

Архитектура API

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

REST

Архитектура репрезентативной передачи состояния (REST), пожалуй, самый популярный подход к созданию API, основанный на клиент-серверном подходе, разделяющий внешний и внутренний интерфейсы и обеспечивающий значительную гибкость в разработке и реализации различных программ. Согласно отчёту Rapid за 2021–2022 гг., 69,3% разработчиков использовали в своей работе REST. Он не имеет состояния, что означает, что API не сохраняет данные или статус между запросами. Он поддерживает кеширование, и в кеше хранятся ответы для медленных или нечувствительных ко времени API.

Формат: JSON, XML, HTML, простой текст

Безопасность: с помощью других инструментов

Обучаемость фреймворку: легкая

Сообщество разработчиков: большое

Для чего используют: чтение, удаление, создание и обновление удаленных объектов

SOAP

Протокол простого доступа к объектам (SOAP) — это стандарт обмена сообщениями, определённый Консорциумом World Wide Web и широко используемый для создания веб-API обычно с XML. Им пользуется, согласно всё тому же отчёту, 23,3% специалистов. SOAP поддерживает широкий спектр коммуникационных протоколов (HTTP, SMTP и TCP/IP), расширяет, а также позволяет разработчикам создавать интерфейсы различными способами и легко добавлять функции и возможности.

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

Формат: XML

Безопасность: высокая

Обучаемость фреймворку: сложная

Сообщество разработчиков: маленькое

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

RPC

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

В отчёте от Rapid сказано, что им пользуется 8,3% опрошенных респондентов.

Формат: JSON, XML, FlutBuffers

Безопасность: встроенная

Обучаемость фреймворку: легкая

Сообщество разработчиков: большое

Для чего используют: сложные вычисления, запуск на сервере

GraphQL

GraphQL — язык запросов и схем данных с эффективным способом взаимодействия между клиентом и сервером. В отличие от REST, где обычно используют GET запросы для получения списка объектов и специфичные ID для получения конкретного объекта, GraphQL позволяет клиенту описывать точный набор данных, которые он хочет получить.

В GraphQL используется единый endpoint, который может предоставлять данные из различных источников и моделей данных на сервере. Это позволяет упростить архитектуру приложения и сократить количество необходимых API-интерфейсов.

GraphQL поддерживает два основных типа операций: запросы (query) и мутации (mutation). Запросы используются для чтения данных, а мутации для изменения или создания новых данных. Также GraphQL поддерживает кэширование ответов на сервере, что значительно сокращает время обработки запросов и повышает производительность приложения.

Формат: JSON

Безопасность: встроенная

Обучаемость фреймворку: средняя

Сообщество разработчиков: развивается

Для чего используют: запрос данных с сервера

Выбор правильного API

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

• Чёткая и полная документация. API — это ПО, и для него требуется исчерпывающая инструкция с практическими рекомендациями и примерами использования. Пример такой документации есть у МТС Exolve.
• Не усложняйте API лишней функциональностью. Чем проще процесс интеграции, тем лучше для сторонних разработчиков. Излишняя сложность вызовет непонимание, и партнёр может отказаться от вашего продукта и выбрать тот, который легче внедрить.
• API должен тестироваться на наличие ошибок и иметь чёткие показатели масштабируемости и производительности (например, сколько вызовов клиент-сервер в секунду может обрабатывать API).
• Безопасность. API-интерфейсы должны поддерживать безопасность посредством чёткой аутентификации, при которой только авторизованные пользователи могут использовать API. Согласно исследованию api-security-trends-report, в 41% организаций за последние 12 месяцев произошли инциденты, связанные с безопасностью API.

Заключение

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