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

Question

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

我知道的：

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

为了让事情变得简单和集中，我忽略了如何为这些请求进行授权。

我的问题：

一旦原始请求的资源准备好（假设这意味着 status="complete"），我该怎么办。

我能想到的最好的是以下之一：

1. 状态响应还将包括（一旦 status="complete"）一个额外的键，例如myresourceId: someuuid客户端可以执行GET /mysomethings/someuuid

2. 状态响应（一旦资源准备好）将包含一个带有资源完整 url 的 Location 标头（例如https://api.example.com/mysomethings/someuuid）

3. 以上两者的组合，以便我同时拥有资源的 url 和它的 id

一些额外的想法：

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

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

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

Answer 1

我的建议是：

URL 必须以简单且独特的方式标识您的资源。前任。：/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 以及与其相关的所有操作。