ASP.NET Web API - несколько долгосрочных вызовов API передовой практики?

Question

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

Сценарий

У меня есть приложение ASP.NET Web API (netcore), которое должно вернуть сложную структуру данных, отформатированную в json. Давайте назовем это WebAPI.NumberOne. Этот внутренний API должен вызывать другую конечную точку API, которая выполняет основную работу, то есть, вызывая внешние API 22, используя шаблон async await с Task.WaitAll, чтобы убедиться, что все external APIs выполнили задание, а затем выполнили некоторую обработку каждого ответа, такую ​​как анализ ответов на тип результата, и, наконец, вернули результат в WebAPI.NumberOne. Я хочу назвать второй WebAPI.NumberTwo.

Ограничение

В настоящее время мы не можем упростить WebAPI.NumberTwo, и он должен выполнять всю эту тяжелую работу насвой. Кроме того, наш клиент не хочет, чтобы в проект были внедрены какие-либо новые технологии, такие как платформы очередей сообщений.

Проблема:

У меня есть эта проблемаполучение тайм-аута от WebAPI.NumberOne, так как другому API иногда требуется около 10 минут для завершения работы. И, возможно, некоторые другие потенциальные риски, о которых я не знаю сейчас.

Мои мысли

1. Я думал о реализации Web Hook Receiver and Listener, чтобы, когдаWebAPI.NumberTwo завершает свою работу с POST результатами для получателя, а с другой стороны, слушатель должен уведомить WebAPI.NumberOne о результатах.
2. Я считаю, что использование концепции служебной шины и очереди сообщений также может бытьвесьма полезно для этого сценария, но поскольку наш клиент не хочет иметь новую технологию на месте, я не стал использовать механизмы очереди сообщений.

Итак, сказав выше, чтокакая-нибудь обычная лучшая практика для таких сценариев? Я более заинтересован в том, чтобы узнать о различных подходах и наилучшей практике, даже несмотря на ограничения, которые я упомянул выше. Цените свое время и помощь.

Answer 1

что мы сделали, так это реализовали организацию очередей с использованием rabbitmq и masstransit (хотя это была бы новая технология для вашего клиента).

Все вызовы API делают в очереди сообщение и возвращают 200 ok.

Потребители сообщений затем вызывают функции, которые выполняют тяжелую работу.

Чтобы интегрировать другие API, мы публикуем событие, и другие потребители API могут затем обработать сообщение.

Учитываятеги на этом посте, возможно, у вас уже есть доступные лазурные очереди или, по крайней мере, msmq.

С вашим предложением webhook, что произойдет, если произойдет сбой или для отдельного компонента потребуется обновление? с очередями сообщение просто остается там до тех пор, пока не будет использовано.