API端点在没有等待承诺的情况下返回的任何不利之处？

Question

要允许快速端点更快地返回给调用者，是否调用异步任务是否合理，但是如果调用者不需要确认，则不等待它再返回就可以吗？

如果异步任务失败，这显然会限制错误处理和重试选项，但是假设您对此并不关心，它的确允许快速API调用更快地完成（假设等待异步任务在语义上没有意义API调用）

与通过API请求调用的其他Web后台作业方法相比，该方法如何？

Answer 1

有时是完全合适的，而在其他时候则是不合适的。这实际上取决于特定的API操作，客户端的期望，客户端可能的使用以及API的记录方式。

例如，核心数据库操作永远不会那样做，因为显然客户端通常需要知道数据库操作是否成功。

但是，一个与广告相关的API只是收集跟踪数据并将其存储起来以备后用，因此它的客户端可能只会忽略该API调用的任何回报，并且如果HTTP能够使整个事情更好地扩展连接可以尽快关闭（无需等待某些存储提交完成）。此外，如果在某些异常情况下丢失了某些此类数据，那也没什么大不了的，客户也不会做任何不同的事情。因此，如果您确定客户端不需要该操作的最终状态，并且在完成异步操作之前结束请求具有规模或性能上的好处，那么它就非常合适。

在另一个示例中，假设您有一个写队列，在将所有N个日志项实际写入磁盘之前，先在内存中排队N个日志项以将它们写入磁盘，因为这样可以显着提高磁盘I / O的可伸缩性和性能。在那种情况下，直到队列达到某个大小触发实际物理写入时，其他客户端的某些将来的请求才对磁盘进行最终写入。为了返回成功的API响应，主机API服务器（甚至对客户端）要等到最后写入之后，这将是一个重大损失。

Answer 2

可以，但是正如您提到的，在重试，监视和同步呼叫方面存在一些缺点。

您可能应该做的是将消息推送到队列中，并请后台工作人员进行处理。将记录保存到代表操作状态的数据库中，然后将消息排队。您可以通过查看刚刚保存的记录的状态（由工作人员更新它）来监视该工作的进度。