Возврат HTTP-ответа без ожидания завершения процесса

#java #spring-boot #http

#java #spring-boot #http

Вопрос:

Я планирую создать rest API, который получает HTTP-запрос от пользовательского интерфейса. этот rest api должен запускать задачу, которая может занять более 1 часа, и мы не хотим, чтобы пользовательский интерфейс ожидал этого ответа. если запрос получен на сервер, мы просто хотим отправить ответ обратно со статусом = ok и позволить задаче на стороне сервера продолжаться. как только задача будет выполнена, она обновит DB со статусом = успех. при сбое будет обновлена база данных со статусом = сбой. чтобы пользователь мог проверить статус задачи в пользовательском интерфейсе, который был извлечен из этой таблицы позже.

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

Спасибо!

Комментарии:

1. 1) Подумали ли вы о том, что вы хотите сделать, если сервер будет перезапущен? — 2) Если задание завершается неудачно, может ли пользователь запросить повторную попытку? — 3) Должна ли система автоматически повторять попытку после задержки, если сбой носит временный характер?

2. Вы рассматривали возможность использования Quartz?

3. Таблица БД с планировщиком cron должна хорошо выполнять эту работу

Ответ №1:

С точки зрения REST API у вас есть возможность асинхронных вызовов с опросом или отправки обновлений в пользовательский интерфейс.

Для опроса это шаги:

  1. Клиент отправляет HTTP-запрос и получает ответ HTTP 202 плюс URL-адрес местоположения для проверки статусов.
  2. Клиент может продолжать отправлять запросы на URL-адрес состояния проверки, который будет возвращать 202, пока результат находится в ожидании.
  3. После завершения работы клиентский запрос на URL-адрес состояния проверки вернет HTTP 302 вместе с URL-адресом конечного ресурса, к которому клиент должен получить доступ.

Вот больше информации об асинхронном шаблоне REST API с опросом: https://docs.microsoft.com/en-us/azure/architecture/patterns/async-request-reply

Если вы предпочитаете передавать результаты клиенту, вы можете заглянуть в WebSockets, как это было рекомендовано другим пользователем. WebSockets имеет очевидные преимущества, но потребует поддержки платформы websockets как в пользовательском интерфейсе, так и на сервере (это довольно хорошо зарекомендовавшая себя платформа, поэтому это не должно быть проблемой). С другой стороны, опрос был бы просто старым HTTP.