基于推送的 api 设计 [关闭]

Question

我正在设计一个 Web API，它将为客户端（其他应用程序）提供推送一些工作请求的机会，立即接收该工作请求的一些 id，然后接收该工作请求的结果。 这种交互的典型方法是什么？ 由于提供工作请求的结果让我想起了服务器推送交互，我想到了 SSE（服务器发送事件）和 webscoket 技术，倾向于 websockets（因为客户端可能对各种请求使用相同的连接并接收各种响应）。这对我的目标来说是一个不错的选择吗？以及如何扩展？

Answer 1

问题是关于 websocket 技术是否适合所描述的 api 设计方法，如果不适合，我想知道什么是更好的方法。这对我的目标来说是一个不错的选择吗？

webSocket 连接非常适合在未来某个不确定的时间接收结果，这是一种推荐的方式。

从客户端到服务器的其他请求可以是 ajax 调用或作为 webSocket 消息发送，主要取决于是否有其他原因将请求作为 ajax 调用。如果您已经建立了 webSocket 连接，那么它是一种方便、简单、快速的与服务器通信的方式。

了解你所做的事情的各个部分：

推送一些工作请求（从客户端到服务器）。

这同样可以通过 Ajax 或 webSocket 完成。如果没有其他原因需要已经建立 webSocket 连接，那么这通常是 Ajax 调用。

立即收到该工作请求的一些 id

对于 Ajax 请求，这实际上更容易一些，因为 Ajax 是一个请求/响应协议，因此如果您通过 Ajax 发送工作请求，那么将 ID 作为对该 Ajax 请求的响应将很简单。你也可以通过 webSocket 来实现，但 webSocket 只是一个消息传递协议。当向服务器发送工作请求时，您可以通过 webSocket 发送它（如前所述）。然后，服务器可以立即发回工作 ID，但客户端必须开发某种方法来将返回的工作 ID 与先前发送的请求相关联，因为这两条消息彼此之间没有任何自然连接。可以进行关联的一种方法是让客户端在发送初始请求时生成一个临时 ID 或哈希值（它实际上可以是该客户端唯一的任何东西，例如时间戳），然后服务器将发送相同的临时发送工作 ID 时返回 ID。对于 HTTP/Ajax 之类的请求/响应协议，所有这些都是微不足道的。

稍后收到该工作请求的结果

HTTP Polling、webSocket 或 SSE 都可以使用。轮询显然不是特别有效。我知道 webSocket 可以完美地解决这个问题，它会为服务器想要以推送方式发送给客户端的任何其他项目提供一个开放的管道。 SSE 也可以用来解决这个问题（将数据推送到客户端），虽然我个人没有任何经验。