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

【问题标题】：Rest API alternative to polling for asynchronous long running tasksRest API 替代轮询异步长时间运行的任务
【发布时间】：2020-01-20 12:40:53
【问题描述】：

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

当前流程：

但是，我们的架构师团队不赞成给客户端提供轮询机制，并要求我们采取另一种方法，可能是回调 URL。他们对此有发言权——“忙着等待睡眠检查任务是否完成，这不是一个好的编程习惯。”

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

【问题讨论】：

“架构师团队。”哈哈。在我看来，他们有责任解释他们关于这是不好的做法的断言并证明额外的工作是合理的；我知道这种情况很少发生，但是如果有经理或其他第三方可以为您仲裁，我会尝试将其重新交给他们。如果他们不喜欢现在的做法，他们应该有责任提出解决方案并让事情顺利进行。
另外，请注意：您可能需要考虑重新审视定义端点的方式； REST is pretty specific 关于这通常是如何完成的。我并不是说这是 API 架构的全部、全部，但是如果您将 API 称为 RESTful，人们可能会对此做出合理的假设，而这些假设不会像您所描述的那样成功你的端点。

【解决方案1】：

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

由于拒绝您的工作流程的既定原因是“良好的编程习惯”，因此您从一个劣势开始，即想出无需进一步信息就可以接受的东西。如果回调 URL 可访问性要求是他们愿意接受的，那当然是一种选择，但我想说您需要非常仔细地考虑故障状态并提醒用户。

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

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

【讨论】：