▶ Способы асинхронного взаимодействия в API
Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.
Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.
Зачем это нужно
👩🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер
Способы асинхронного взаимодействия в API
1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ Пример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис
2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡ Пример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса
3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡ Пример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ
4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу
5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот
⭐️ Подборка материалов доступна в закрытом канале
#интеграции #async
Обзор посвящён асинхрону в API. Асинхрон в брокерах сообщений смотрите в этом посте. А здесь можно найти вводный пост по асинхронным интеграциям.
Асинхрон в API позволяет клиентским приложениям отправлять запросы на сервер и продолжать работу без ожидания ответа.
Зачем это нужно
👩🏫Клиент не блокируется в ожидании ответа. Важно для операций, требующих значительного времени на обработку
🧑🏫Сервер может обрабатывать больше запросов за счет асинхронной обработки
👨🏫Уменьшается количество необходимых запросов для получения обновленных данных, снижая нагрузку на сервер
Способы асинхронного взаимодействия в API
1⃣ Webhooks
1. Клиент отправляет запрос серверу, указывая сallback URL
2. Сервер принимает запрос и отвечает клиенту, что запрос принят в обработку (например, 202 Accepted)
3. Сервер обрабатывает запрос и отправляет клиенту запрос с результатами на сallback URL
➡ Пример: GitHub Webhooks отправляют автоматические уведомления о событиях в репозитории (например, push или pull request) на конфигурированный внешний сервис
2⃣ Polling
Клиент отправляет запрос на сервер, а затем раз в Т миллисекунд отправляет запросы к серверу, чтобы проверить статус операции
➡ Пример:
1. Пользователь заполняет анкету и загружает скан паспорта
2. Фронт отправляет файл на сервер, получает 202 Accepted и позволяет пользователю заполнять анкету дальше
3. Сервер начинает процесс распознавания паспортных данных, который в среднем занимает 5-7 секунд.
4. Приложение запускает фоновый процесс поллинга: раз в 1 секунду отправляет запрос для получения статуса обработки запроса
3⃣ Long Polling
Сервер получает запрос, но держит его открытым до момента появления новых данных. Это уменьшает количество запросов по сравнению с обычным поллингом. Работает на протоколе HTTP. После получения данных от сервера соединение закрывается.
➡ Пример: чат-приложения, где сервер держит соединение открытым до появления новых сообщений, и только после этого отправляет ответ
4⃣ Server-Sent Events (SSE)
Однонаправленный канал связи от сервера к клиенту, позволяющий серверу посылать события клиенту через открытое соединение. В отличие от Long Polling клиент может получать несколько событий и данных от сервера без необходимости устанавливать соединение заново.
➡ Торговые платформы в реальном времени, где клиенты получают обновления цен акций без необходимости постоянного запроса к серверу
5⃣ WebSocket API
Протокол, обеспечивающий двустороннее постоянное соединение между клиентом и сервером, позволяя обмениваться данными в реальном времени. Это именно отдельный протокол (не НTTP), клиент и сервер могут без задержек обмениваться данными в обе стороны, без необходимости устанавливать и закрывать соединения по несколько раз.
➡ Онлайн-игры, интерактивные приложения, где требуется немедленная реакция сервера на действия пользователя и наоборот
⭐️ Подборка материалов доступна в закрытом канале
#интеграции #async