Открыть сервис
Главная → Блог → API вызов

API вызов

API-вызов (от англ. Application Programming Interface call) — это единичный запрос, отправляемый одним программным компонентом (клиентом) к другому (серверу или сервису) через заранее определённый интерфейс (API). В ответ на вызов сервер выполняет некоторое действие (например, возвращает данные, изменяет состояние ресурса, запускает процесс) и отправляет клиенту ответ. API-вызовы являются фундаментальной единицей взаимодействия в современных распределённых системах, микросервисной архитектуре, облачных вычислениях и веб-разработке.

История

Концепция API-вызовов возникла вместе с появлением первых операционных систем и библиотек подпрограмм. В 1960-х годах вызовы функций в языках программирования (например, в Фортране или Алголе) можно считать прообразом API-вызовов. С развитием сетевых технологий в 1980-х годах появились удалённые вызовы процедур (RPC), которые позволяли программам на одном компьютере вызывать функции на другом. В 1990-х годах с распространением веба возникли протоколы SOAP и XML-RPC, а затем, в 2000-х, — REST (Representational State Transfer), ставший доминирующим стилем для веб-API. В 2010-х годах набрали популярность GraphQL и gRPC, предлагающие альтернативные модели вызовов.

Классификация API-вызовов

API-вызовы можно классифицировать по нескольким признакам.

По протоколу передачи

  • HTTP/HTTPS-вызовы — наиболее распространённый тип. Клиент отправляет HTTP-запрос (GET, POST, PUT, DELETE, PATCH и др.) на URL-адрес сервера. Сервер возвращает HTTP-ответ с кодом состояния (200, 404, 500 и т.д.) и телом сообщения (обычно в формате JSON или XML).
  • gRPC-вызовы — используют протокол HTTP/2 и бинарный формат сериализации Protocol Buffers (protobuf). Обеспечивают высокую производительность и строгую типизацию.
  • WebSocket-вызовы — устанавливают постоянное двустороннее соединение, позволяя серверу инициировать отправку данных клиенту без явного запроса.
  • Вызовы через очереди сообщений (Message Queue) — клиент помещает сообщение в очередь, а сервер (или несколько серверов) асинхронно его обрабатывает. Примеры: RabbitMQ, Apache Kafka, Amazon SQS.

По синхронности

  • Синхронные вызовы — клиент отправляет запрос и блокирует своё выполнение до получения ответа. Это простейшая модель, но она может приводить к задержкам, если сервер отвечает долго.
  • Асинхронные вызовы — клиент отправляет запрос и продолжает работу, не дожидаясь ответа. Ответ может быть получен позже через колбэк, промис, событие или отдельный канал. Асинхронность повышает отзывчивость и пропускную способность системы.

По типу действия (в стиле REST)

В RESTful API вызовы обычно соответствуют операциям CRUD (Create, Read, Update, Delete):

  • GET — получение данных (чтение).
  • POST — создание нового ресурса или отправка данных на обработку.
  • PUT — полная замена существующего ресурса.
  • PATCH — частичное обновление ресурса.
  • DELETE — удаление ресурса.

По способу аутентификации

  • Без аутентификации — открытые публичные API.
  • С API-ключом — простая идентификация клиента по ключу, передаваемому в заголовке или параметре запроса.
  • С токеном (JWT, OAuth 2.0) — клиент получает токен доступа и передаёт его в каждом вызове для авторизации.
  • С базовой аутентификацией (Basic Auth) — передача имени пользователя и пароля в заголовке Authorization.

Устройство и характеристики

Типичный API-вызов состоит из нескольких частей:

  1. Конечная точка (Endpoint) — URL-адрес, по которому доступен ресурс или функция.
  2. Метод (HTTP-метод или имя процедуры) — определяет тип операции.
  3. Заголовки (Headers) — метаданные запроса (тип содержимого, аутентификация, кэширование и т.д.).
  4. Тело запроса (Body) — данные, передаваемые серверу (для POST, PUT, PATCH). Может отсутствовать.
  5. Параметры (Query parameters или Path parameters) — дополнительные данные, встраиваемые в URL.
  6. Ответ — содержит код состояния, заголовки и тело ответа (или пустое тело).

Ключевые характеристики

  • Время отклика (Latency) — время между отправкой запроса и получением ответа. Измеряется в миллисекундах.
  • Пропускная способность (Throughput) — количество вызовов, которое система может обработать за единицу времени (например, запросов в секунду).
  • Надёжность — способность корректно обрабатывать вызовы при сбоях сети, сервера или клиента. Часто реализуется через повторные попытки (retries) и идемпотентность.
  • Безопасность — защита от несанкционированного доступа, инъекций, DDoS-атак и других угроз.

Применение

API-вызовы используются практически во всех современных программных системах.

Веб-разработка

  • Фронтенд-приложения (React, Vue, Angular) отправляют API-вызовы к бэкенду для получения и отправки данных.
  • Серверные приложения (Node.js, Python, Java) вызывают API сторонних сервисов: платёжных шлюзов, сервисов электронной почты, картографических сервисов (например, Яндекс.Карты), социальных сетей.
  • Микросервисы общаются друг с другом через API-вызовы по HTTP или gRPC.

Мобильные приложения

  • Мобильные приложения (iOS, Android) практически полностью полагаются на API-вызовы к серверу для работы с данными, аутентификации и синхронизации.

Интеграция систем

  • API-вызовы используются для интеграции корпоративных систем (ERP, CRM, бухгалтерия) между собой или с облачными платформами.
  • Облачные сервисы (AWS, Google Cloud, Яндекс.Облако) предоставляют API для управления ресурсами (виртуальными машинами, базами данных, хранилищами).

Интернет вещей (IoT)

  • Устройства (датчики, умные лампы, термостаты) отправляют API-вызовы на сервер для передачи показаний или получения команд.

Искусственный интеллект и машинное обучение

  • API-вызовы к сервисам распознавания изображений, обработки естественного языка (например, YandexGPT) или синтеза речи.

Примеры

  1. Получение списка пользователей (REST):
  1. Создание нового заказа (REST):
  • Запрос: POST https://api.example.com/orders с телом {"product": "Книга", "quantity": 1}`
  • Ответ: {"orderId": 12345, "status": "created"}
  1. Вызов функции через gRPC:
  • Клиент вызывает метод GetUser с параметром {user_id: 42}.
  • Сервер возвращает объект User с полями name, email, created_at.

Критика и ограничения

  • Зависимость от сети — API-вызовы требуют стабильного сетевого соединения. При его отсутствии или высокой задержке система может стать недоступной.
  • Избыточность — при частых вызовах для получения небольших объёмов данных может возникать сетевая нагрузка и задержки. Для решения применяются пакетные запросы (batch) и кэширование.
  • Сложность версионирования — изменение API может нарушить работу старых клиентов. Требуется тщательное управление версиями (через URL, заголовки или параметры).
  • Безопасность — открытые API могут быть уязвимы для атак (SQL-инъекции, подделка запросов, утечка данных). Необходимы строгие меры аутентификации, авторизации и валидации.
  • Необходимость документирования — без чёткой документации (например, в формате OpenAPI/Swagger) разработчикам трудно использовать API.

Интересные факты

  • Первый задокументированный API для веба был создан компанией Salesforce в 2000 году.
  • По оценкам, в 2023 году в мире ежедневно совершается более 100 миллиардов API-вызовов.
  • Компания Google обрабатывает более 3 миллиардов API-вызовов в день только для своих картографических сервисов.
  • Стандарт OpenAPI (ранее Swagger) позволяет автоматически генерировать документацию, клиентские библиотеки и тесты для REST API.

Источники

  • Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures (докторская диссертация). Глава 5 — Representational State Transfer (REST).
  • Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly Media.
  • Документация OpenAPI Specification (Swagger).
  • Стандарт gRPC: grpc.io.
  • Материалы курсов по архитектуре программного обеспечения (Coursera, edX).

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы