异步长时间运行任务轮询的Rest API替代方案

我创建了一个flask restplus API，它接受xlsx文件作为输入并返回XML。这将由我们不同的API在内部使用

当前流量：

• 用户通过调用/上载端点发布xlsx文件
• API接受文件，存储它并返回文件id
• 用户通过提供的文件id向/运行另一个请求 加工
• API将请求放入rabbitMQ队列，并返回202和 用于轮询状态的位置URL
• 芹菜工人拿起请求并开始处理它。需要 需要一段时间才能完成
• 同时，用户可以对状态进行轮询
• 一旦完成，API将发送303，并将另一个位置URL发送到 下载文件
• 用户点击新的URL下载文件

然而，我们的架构师团队不赞成为客户端提供轮询机制，并要求我们采取另一种方法，可能是回调URL。 他们有一个说法——“忙着用睡眠来等待任务是否完成，这不是一个好的编程实践。”

---

我想知道客户是否可以在不进行状态轮询的情况下采取任何不同的方法。回调是我知道的，但它还没有到位。

使用回调URL至少有一个潜在的重要要求：客户端必须在静态位置通过共享网络直接访问。如果可以假设所有可能的客户端都满足此要求并接受来自API的连接，那么这不一定是一个问题，但这些信息无疑是至关重要的，如果在某个时候人们想从桌面应用程序等使用此API，那么添加此要求可能会导致严重的麻烦

由于拒绝工作流的原因是“良好的编程实践”，因此在提出一些无需进一步信息即可被接受的内容时，您从一个劣势开始。如果回调URL可访问性要求是他们愿意接受的，那当然是一种选择，但我想说的是，您需要非常小心地解释并提醒用户有关失败状态的信息

另一种可能是一个单独的多功能端点，它要么调用其他端点本身并阻塞，要么直接执行内部，而不需要中间请求（尽管这可能需要您自己进行轮询、绕过队列，或者在完成文件处理时使用您自己的内部回调来完成请求）

---

我还将重新审视所提供的任何需求，并确定它们如何以及为什么不正确或不足以充分定义可接受的交付成果（或者是否存在误解）。这似乎不太可能是一次性的问题，如果有一个流程修复或类似内部开发指南的内容，可能会限制未来的误解或架构分歧，那么这是值得研究的。

“架构师团队。”哈哈。在我看来，他们有责任解释他们关于这是一种不好的做法的断言，并为额外的工作辩护；我知道这种情况很少发生，但如果有经理或其他第三方可以为你仲裁，我会尝试把这件事推还给他们。如果他们不喜欢现在的做法，这应该是他们的责任Y，提出一个解决方案，让球滚动。同样，请注意：您可能想考虑如何定义端点；关于这是如何完成的。我并不是说这是所有API架构的全部，但如果您调用API的REST，人们很可能对它做出合理的假设。将按照您描述端点的方式进行平移。