Привет!

Ещё один пост про асинхронную интеграцию продолжая серию.

Это уже непосредственно из моей практики, потому что я часто люблю на собеседованиях задавать вопрос: "Как ты думаешь, можно ли реализовать асинхронную интеграцию через REST?".

Не читая дальше - подумайте сами, как бы вы на него ответили и напишите в комментарии.

Вопрос на самом деле чисто на хорошее понимание REST или умение размышлять, зависит от того, знаешь ли ты ответ заранее и сталкивался ли с таким или нет (невзначай ввернул посыл про то, что если ты не знаешь какой-то ответ на вопрос - не нужно сразу сдаваться, а нужно подумать, потому что именно размышлений на этой позиции от вас и ждут).

Отвлекся.
Так вот, на самом деле сразу хочется ответить, что нет - нельзя. Но это не совсем так, иначе бы я не спрашивал скорее всего)

Стандартное взаимодействие между системами выглядит как цепочка синхронных запросов, выполняющихся подряд между микросервисами. Условно: front -> rest api -> rest api -> rest api и потом это все также синхронно возвращается по цепочке обратно. Это достаточно долго по меркам системы, так как все это время пользователь видит loader (бегающий кружочек загрузки) и не может продолжать взаимодействовать с системой (см. картинку один). Это не очень круто.

Тут сразу несколько вариантов:
1. Можно отправить из одной системы в другую REST-запрос, который инициирует процесс, но вызывающая сторона не будет ждать пока завершится вся цепочка целиком, а получит ответ только от одного сервиса о том, что процесс запущен.
Для примера, это может быть процесс формирования документов. То есть ты на фронте нажал кнопку "Сформировать документы", фронт вызвал какой-нибудь микросервис-адаптер, тот вернул успешный ответ с HTTP-кодом = 200, по сути подтвердив, что процесс запущен (параллельно пошел вызывать микросервисы по цепочке дальше), а фронт уже отрисовал пользователю сообщение с текстом "Процесс формирования документов успешно запущен" и отпустил пользователя с миром работать дальше (см. картинку два).

Но тут важно понимать, что т.к. это всё еще синхронные REST-запросы, то если в одном месте этой цепочки, уже после вызова с фронта, что-то пойдет не так - то процесс оборвется, документы не сформируются и пользователь об этом даже не узнает. Именно поэтому и существует такая штука как очереди сообщений. Но если это не очень критично (есть такие места и процессы) или просто надо на коленке что-то быстро сваять - вполне себе рабочий вариант.

2. Callback URL - такая интересная шутка, появившаяся в версии 3.0 OpenAPI specification. Это работает так, что посылая REST-запрос в какой-нибудь сервис, ты можешь указать в специальном параметре callbackURL эндпоинт, на который сервис должен прислать результат после того, как он закончит свою работу.
Т.е. если послать запрос POST /api.example.com/foo?callbackURL=http://my.server.com/bar, то после того как метод /foo закончит свою работу, он пошлет запрос с результатом выполнение на адрес http://my.server.com/bar.

Если еще проще, то это можно воспринимать как письмо. Вам пришло письмо с просьбой заполнить какую-нибудь форму а затем вернуть ее по предварительно указанному адресу, который находится в доставленном вам конверте. Заполнили форму - отприли обратное письмо по этому адресу.
Это особенно полезно, когда обработка некоторых данных может занимать длительное время. На предыдущем примере - если формирование документов занимает 5 минут, то мы не можем заставить пользователя ждать это время. Поэтому мы просто посылаем запрос такого рода, нам приходит подтверждение о том, что наш запрос получен и взят в работу. Через какое-то время, после завершения обработки этого запроса - нам вернется ответ со всей нужной информацией (в нашем случае со сформированными документами).

Есть еще третий вариант, там никаких хитростей нет. Попробуйте написать ваши предположения в комментариях.