Способы асинхронного взаимодействия в API
Обзор по свящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.
Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.
Зачем это нужно
- Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку.
- Сервер может обрабатывать больше запросов за счет асинхронной обработки.
- Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер.
Способы асинхронного взаимодействия в API
1. Webhooks
- Клиент отправляет запрос серверу, указывая сallback URL.
- Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted).
- Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL.
Пример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис.
2. Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции.
Пример:
- Пользователь заполняет анкету и загружает скан паспорта.
- Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше.
- Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
- Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса.
3. Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
Пример: Чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ.
4. Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
Пример: Торговые платформы в реальном времени, где клиенты получ ают обновления цен акций без необходимости постоянного запроса к серверу.
5. WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не HTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
Пример: Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот.
Подборка материалов
Статьи
- Как мы доставляем сообщения с сервера на клиент в реальном времени (Superjob)
- Примеры асинхронных API
- VK: Зачем нужны очереди сообщений в микросервисной архитектуре
- SA: Интеграция, управляемая сервером (Опрос, долгий опрос и вебхуки)
- Создание приложений реального времени с помощью SSE
- Polling и long polling
- API-callbacks
- Callback API ВКонтакте
- Как использовать Websocket на примере
- Что такое веб-сокеты
- Server-Sent Events: пример использования
- Сравнение способов асинхронных интеграций (англ)
- HTTP/2 лонг поллинг vs вебсокеты
- Сравнение поллинга и лонг поллинга
Видео
- Что такое Webhook за 12 минут
- Что такое веб-сокеты за 4 минуты
- Сравение Webhook и Long Polling
- Убьет ли HTTP/2 лонг поллинг и вебсокеты
- Server-Sent Events: Простая замена веб-сокетам
- Server-Sent Events: Снимаем ограничения
- Собеседование на системного аналитика: разбор задачи на асинхронные запросы в REST API