如何设计可能需要太长时间的 API 后端请求

Question

假设我有一个 API 端点，它生成一个 PDF 文件，其中包含客户端发送的大量图像。服务器可以尝试通过在下载图像之前获取图像大小来估计需要多长时间，但它不能考虑繁忙/缓慢的网络峰值。所以，很明显，服务器只是返回一个“正在进行”的信号，并在文件完成后发送一封电子邮件或其他东西，对吧？但是如果用户发送了非常小的图像样本并且发送电子邮件是不必要的怎么办？是否可以确定地考虑这一点？服务器是否可以计算出这个文件最终会如此之小，以至于它肯定可以直接发送它而不会从浏览器中获得超时？我是全栈开发的新手，但我相信这一定是一个常见问题，有什么名字吗？考虑到以下情况，此问题的常见解决方法和解决方案是什么：1）向用户发送电子邮件不是理想的解决方案2) 在文件创建期间流式传输文件是不可能的。3) 如果用户放弃/关闭浏览器/失去连接/等，应停止处理。

Answer 1

检测连接不再处于活动状态应该相当容易。那么为什么不在完成渲染文件后检查连接是否处于活动状态，如果它仍然处于活动状态，则立即将其发送回去。如果不是，那么您可以通过电子邮件发送文件。此外，如果您正在将文件发回并且浏览器超时，则只需通过电子邮件发送文件。

就估计所有这些事情而言，如何估计这些事情没有完美的解决方案。您不可能知道是否有人在地铁中通过手机使用您的网站，然后突然进入隧道而失去所有服务。

Answer 2

可以简化您的客户端处理不同响应代码和格式的需求的一种选择是让您的 API 返回一个HTTP 202 (Accepted)，并返回一个id代表新 PDF 的资源 ID 的 。在这种情况下，API 可以立即响应并执行创建 PDF 所需的任何异步处理。然后，客户端可以通过单独的端点（例如 ）从您的 API 查询资源GET /pdf/<id>。如果 PDF 仍在处理中，您的 API 将只返回 404，直到它完成。

如果您不想让客户端持续轮询 API，您可以定义一个特定的时间阈值，您愿意在默认发送电子邮件之前等待。例如，在调用 API 后立即启动计时器并开始生成 PDF，如果计时器超过您愿意接受的阈值，则HTTP 202在处理完成后返回 a并可选择发送电子邮件。如果 PDF 生成在时间阈值之前完成，则HTTP 2xx在响应中返回带有 PDF 文件的 a。