Пользователь смотрит на индикатор загрузки. Запрос занимает ресурсы сервера. Балансировщик обрывает соединение по тайм-ауту. Клиент повторяет запрос — и один отчёт строится уже дважды. Здесь поможет перенос долгой операции в фоновую обработку.
Как выглядит схема:
• Клиент отправляет
POST /reports.• API ставит задачу в очередь и быстро возвращает
202 Accepted с заголовком Location: /reports/42.• Фоновый воркер забирает задачу и выполняет пятиминутную работу.
• Клиент запрашивает
GET /reports/42 и получает статус Running.• При следующей проверке получает
Done и ссылку на результат.Что это даёт:
• HTTP-запросы завершаются быстро, не дожидаясь построения отчёта.
• Длительность фоновой задачи больше не упирается в тайм-аут запроса.
• Воркеры масштабируются независимо от API.
• Повторная проверка статуса не запускает создание отчёта заново.
Для безопасного повторения самого
POST предусмотрите ключ идемпотентности, чтобы не создавать дубликаты задач.Ещё две детали:
• Возвращайте
Retry-After, чтобы клиент понимал, через какое время снова проверить статус.• Используйте SignalR или webhook, если нужно уведомлять о готовности вместо периодических запросов.
Длительная операция становится отдельным ресурсом: её можно создать, проверить состояние и получить результат. А как вы обрабатываете долгие задачи в своих API: polling, webhooks или SignalR?
👉 @KodBlog