К синхронным или асинхронным интеграциям относится REST

Что проверяют

Понимаете ли вы, что синхронность это свойство взаимодействия, а не протокола, и умеете ли выбрать способ интеграции под задачу. Следом почти всегда спрашивают, как через REST провести долгую операцию и когда вместо него лучше брокер сообщений.

Как отвечать

Короткий ответ: REST относится к синхронным интеграциям. Это архитектурный стиль поверх HTTP, а HTTP устроен как «запрос-ответ»: вызывающая система отправляет запрос и в рамках того же обмена ждёт результат или ошибку с кодом статуса.

Дальше покажите, что граница не такая жёсткая:

• синхронная интеграция: вызывающая сторона ждёт ответа, обе системы должны быть доступны одновременно, отказ или медленный ответ одной сразу бьёт по другой;
• асинхронная интеграция: отправитель кладёт сообщение и идёт дальше, получатель обработает его, когда сможет. Типичные инструменты: Kafka, RabbitMQ, облачные очереди;
• асинхронный сценарий поверх REST: сервер отвечает 202 Accepted и ссылкой на статус операции, клиент опрашивает её или получает результат обратным вызовом (webhook). Каждый отдельный вызов синхронный, а бизнес-процесс уже асинхронный.

Для аналитика важно назвать критерии выбора. REST подходит, когда ответ нужен сразу: проверить остаток, получить карточку клиента, авторизовать платёж. Брокер уместен, когда получатель бывает недоступен, событие нужно нескольким системам или поток большой и неровный. В спецификации интеграции при этом фиксируют таймауты, число повторов, идемпотентность и поведение при недоступности смежной системы.

Где спотыкаются

Путают асинхронный код клиента с асинхронной интеграцией. async/await или неблокирующий HTTP-клиент освобождают поток, но схема взаимодействия не меняется: ответ всё равно приходит в рамках того же вызова.

Называют REST протоколом. Протокол здесь HTTP, а REST это набор принципов: ресурсы, единый интерфейс, отсутствие состояния на сервере между запросами.

Не думают о сбоях. Синхронная цепочка из пяти сервисов падает, если упал любой из них, а повтор неидемпотентного POST без ключа идемпотентности создаёт дубль заказа.