小编har*_*ari的帖子

问题是如何设计执行耗时作业（几秒和几分钟的数量级）的 REST Web 服务。

最快的解决方案是按如下方式进行：

1. 客户端向服务器发送 POST 请求（POST /job），响应的 HTTP 状态为 202，并将包含作业 ID；
2. 客户端使用 GET 定期询问作业状态（例如GET /job/:id/status）；
3. 当作业完成时，客户端使用 GET 请求结果（例如GET /job/:id/result）。

我不喜欢的是步骤 2，因为许多作业正在进行中，服务器不必要地超载。为了避免这种情况，我想到了另外两种解决方案：

• 当客户端执行第一个 POST 请求时，它还会给出一个 URL，可用作服务器的回调。当服务器结束阐述时，它将通过 GET/POST 请求通知此 URL 上的客户端；
• 服务器提供WebSocket，客户端可以在其中注册并获取作业完成的“通知”；

所有三个解决方案都有我不喜欢的方面：

1. 轮询：服务器过载；
2. 回调：客户端必须向服务器提供可用的 URL；
3. websocket：为什么要向 REST Web 服务引入另一种“技术”？也许，到那时，最好只使用 websocket 来完成所有请求。

还有其他解决方案吗？如果不是，您认为这三个中哪一个更可靠？