构建需要很长时间才能响应的 API 的最佳实践是啥？

Posted 2023-03-07

【中文标题】构建需要很长时间才能响应的 API 的最佳实践是啥？

【英文标题】：What is the best practice for building an API that takes a long time to respond?构建需要很长时间才能响应的 API 的最佳实践是什么？

【发布时间】：2020-07-21 12:34:59

【问题描述】：

我正在构建一个 API 端点，它必须调用多个外部服务/数据库，我不希望我的用户必须等待这个过程发生，但是，这个过程的结果对我的用户来说是必不可少的。

我的第一个想法是将请求添加到队列并立即返回，然后在稍后的某个时间，用户可以查询不同的端点以获得结果。

有没有更好的方法来解决这个问题？是否应该有一个 webhook 响应，而不是要求用户查询 API 两次？

【参考方案1】：

我见过的三种主要方式：

客户端发送 API 请求并立即获取作业编号。然后，客户端可以每隔一段时间（每分钟左右，取决于通常的结果需要多长时间）发送带有该作业编号的不同 API 请求，以便检查进度。在其中一项检查中，工作将完成并获取数据。

客户端建立webSocket 或socket.io 连接。客户端通过该 websocket/socket.io 连接发送请求。服务器开始处理结果。结果完成后，会立即通过 webSocket/socket.io 连接将其发送回客户端。然后客户端可以为其他请求保持 websocket/socket.io 连接连接或关闭连接。

使用Server-Sent events。发送查询，然后当结果完成后，服务器可以在同一连接上将其发回。

我认为这三者之间没有“最佳实践”，因为它们都有一些优点和一些可能相关的其他用途。轮询选项 #1 是最小的公分母，适用于任何情况，但需要客户端的轮询策略并且可能有一些延迟（在客户端轮询之前准备好结果）。

选择#2 和#3 都非常有效，它们的通用技术也可能有其他用途。

【讨论】：

好答案！但是，您能否添加有关如何处理面向用户的页面的详细信息？就像在页面加载时填充默认值以及在我们获取详细信息时更新它们一样？

@LearningEveryday - 这是您自己的用户界面设计选择。您可能会在屏幕上的某处向用户显示结果“正在进行中”。无论您是在标题中的字形中执行此操作，他们可以在结果时单击，并且您允许他们在等待时在您的站点上执行其他操作，或者您是否占据整个页面并仅显示一些动画表明它仍在等待真的取决于您以及它如何适应您的应用程序的上下文。

啊！谢谢！题外话，你有没有推荐什么好书来了解更多？

@LearningEveryday - 我不知道任何关于这个一般概念的书。 socket.io 和 webSocket 上有多本书籍，您可以通过简单的搜索在 Amazon 上找到它们。服务器发送的事件中甚至还有一个here。