Асинхронно вернуть HTTP-код состояния 202 для службы REST?

Question

У нас есть служба REST, которая вызывает системный процесс, который может занять до 2 минут. Поскольку на клиентах я не хочу ждать ответа от сервера от 30 секунд до 2 минут, могу ли я вернуть клиенту 202, чтобы сообщить, что он обрабатывается, но не обязательно ждать, пока процесс закончить?

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

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

Заранее спасибо

EDIT Конечный продукт - это отчет в формате PDF, который генерируется, а затем отправляется пользователю по электронной почте. В основном я пытаюсь обойти необходимость ждать ~ 2 минуты ожидания ответа службы на клиенте-потребителе.

Answer 1

Я думаю, что немедленный возврат 202 из сервиса - это нормально, поскольку он подтверждает успешное получение запроса на создание PDF.

Ваш план для регистрации ожидающих запросов в БД и их обработки в пакетах имеет смысл для меня. Если каждый файл PDF помечается как «готово» после того, как файл PDF был отправлен без ошибок (например, система очередей сообщений / рабочая роль), я думаю, что он будет работать нормально.

Если вы не хотите идти по маршруту БД, ваша конечная точка службы может породить другое асинхронное задание, а затем вернуть 202. Таким образом задание pdf запускается немедленно и клиента получает немедленный ответ - но это кажется немного беспорядочным ИМО.

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

Answer 2

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