任务越大，依赖于单个HTTP请求/响应的解决方案就越脆弱。想象一下，任务完成99%后连接断开，客户端将不得不重复整个过程。
相反，我建议使用如下依赖于几个HTTP请求的模式：

• 客户端（浏览器）发出类似POST /starttask的请求以启动任务，并在响应中接收“任务ID”。
• 任务在服务器上运行，而客户端可以做其他事情。任务计算的任何结果都存储在任务ID下的数据库中。
• 客户端可以通过发出GET /task/<taskID>之类的常规请求来检查任务进度，并接收进度通知（完成50%），这可以用于在UI上动画显示“进度条”。
• 当任务100%完成并产生了客户机需要知道的结果时，它可以使用类似GET /taskresult/<taskID>的请求检索该结果。
• 如果任务结果很大，客户机可能需要重复结果检索，可能需要分页（GET /taskresult/<taskID>?page=1等），直到接收并处理完整个结果，这不会给服务器带来太大负担，因为它只是从数据库读取任务结果。
• 最后，客户端可以使用另一个请求（如POST /taskcleanup/<taskID>）从服务器数据库中删除任务结果。

使用await / async可以工作，因为它将永远等待，直到一个承诺（请求到后端）已经履行。你可以向用户显示某种加载图形，这是其他网站如何处理冗长的任务。
取决于任务的大小，但举例来说，如果任务相当小（例如10秒），我们可以使用"正在加载“状态作为识别是否应显示加载图形的方式：

function example() {
    setLoading(true);
    try {
        const response = await axios.get('/user?ID=12345');
        console.log(response);
      } catch (error) {
        console.error(error);
      } finally {
        setLoading(false);
      }
}

Axios Minimal Example

我认为保持连接打开等待响应几分钟是不好的。
相反，我建议SignalR服务器端通知（或等效）通知前端有关任务更新。
通知DTO将包含有关任务的所有所需信息。
后端：

// Post method
void startTask(params) {
    // start backend processing
    // after completion notify
    signalRHub.notify();
}

在前端，您只需要订阅通知并为它们添加处理程序。