💥 Виды API: когда и какой выбрать 💥

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

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


Основные виды API:
⚡ HTTP
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
⚡ SSE


В деталях 👇

⚡ HTTP API
Использует HTTP-протокол.
Часто это более “простые” API без строгого следования REST-подходу.
Во многих таких API чаще встречаются только методы GET / POST, но могут использоваться и другие.

Пример: Unisender


⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепции ресурсов и стандартных HTTP-методов (GET, POST, PUT, PATCH, DELETE и др.).

Это архитектурный стиль проектирования API поверх HTTP.

Широко используется для веб- и мобильных приложений, а также в микросервисной архитектуре.

Пример: Wildberries


⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает стандартизированные подходы к безопасности и описанию операций.

Часто применяется в корпоративных системах (enterprise), где важны строгие контракты, формализация и совместимость, а также повышенная безопасность.

Сегодня для новых проектов SOAP выбирают реже, так как REST/gRPC часто проще и легче в реализации и сопровождении.

Пример: PayPal


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

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

Пример документации:
Яндекс.Погода


⚡ gRPC
Использует Protocol Buffers (protobuf) для сериализации данных и обычно работает поверх HTTP/2.

Поддерживает разные типы взаимодействия, включая стриминг (в т.ч. двусторонний).

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

Пример: Dropbox от Google


⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.

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

Пример: Binance Биржа


⚡ SSE (Server-Sent Events)
Механизм, при котором сервер может в реальном времени отправлять обновления клиенту по одному HTTP-соединению.

В отличие от WebSocket, SSE обычно используется для односторонней передачи данных (от сервера к клиенту).

Подходит для сценариев, где нужно показывать обновления без постоянного опроса сервера:
+ уведомления
+ статусы задач
+ обновление ленты событий
+ прогресс обработки
+ live-обновления на дашбордах

Обычно проще в реализации, чем WebSocket, если не нужна двусторонняя связь.



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

✅ корректно описывать требования к интеграциям,

✅ учитывать ограничения по производительности, безопасности и формату данных,

✅ и выбирать реалистичный вариант взаимодействия между системами, сервисами и микросервисами.

#АрхитектураGA