具有状态轮询的异步ReST（以及如何最终接收完成的结果）

Question

我的请求预计需要几个小时才能完成，而我无法弄清楚整个流程。我知道这已经多次讨论过了，包括here，但我发现没有回答下面的问题（令人信服）。

我所知道的：

1. 我会做POST /mysomethings
2. 回复将是202 Accepted，其中包含Location标题，其中包含可以找到状态的完整网址（例如https://api.example.com/statuses/somestatusuuid）。
3. 然后，客户端可以轮询状态网址并获得200 OK响应，其响应正文包含{ statusId: someid, status: somestatusstring, description: somestatusdescriptionstring }
之类的内容

为了保持简单和专注，我忽略了如何对这些请求进行授权。

我的问题：

原始请求的资源准备就绪后我该怎么办（让我们说这意味着状态=“完成”）。

我能想到的最好的就是其中之一：

1. 状态响应还包括（一次状态=“完成”）其他密钥，例如myresourceId: someuuid，然后客户端可以执行GET /mysomethings/someuuid

2. 状态响应（资源准备就绪后）将包含一个Location标头，其中包含资源的完整网址（例如https://api.example.com/mysomethings/someuuid）

3. 以上两者的组合，以便我同时拥有资源的网址及其ID

一些额外的想法：

• IMO在状态请求中返回资源本身是不合适的，因为请求的是状态而不是实际资源。

• 我也不喜欢在某些地方建议的想法返回202状态，直到资源准备好然后返回201 Created因为状态代码应该传达请求的状态，而不是资源（绝对不是当前请求仅请求其状态的另一资源）。

这一切听起来都对吗？欢迎任何和所有评论。

Answer 1

虽然您使用HTTP 202代码丢弃了该选项，但您几乎已经描述了RFC 2616规范定义的使用201/202 HTTP响应的情况。

不是返回HTTP 200代码并使用404，而是让服务器返回HTTP 202（已接受）并编写客户端代码进行轮询，直到在Location头中收到带有新资源URI的HTTP 201（已创建）（或者发生超时期限。）

Answer 2

我建议：

网址必须以简单的方式识别您的资源。例：/items/123456

• GET /items/123456将返回资源本身
• POST /items/123456可以上传资源（创建或替换）
• GET /items/123456/status将提供与资源相关的状态和元数据（例如JSON中的描述性数据）

您只需使用这3项服务即可实现这一目标。 GET资源将回答404 NOT_FOUND或200 OK，具体取决于资源状态。

状态也可以使用参数GET /items/123456?status来完成，以便只保留资源的一个URL以及与之相关的所有操作。