异步任务的 HTTP 状态码答案

【问题标题】：HTTP status code for async tasks异步任务的 HTTP 状态码
【发布时间】：2016-04-05 09:01:55
【问题描述】：

我正在实现一个 REST API，它涉及在服务器上创建一个对象。对象创建涉及多个步骤，可能需要一段时间。我不希望用户等待它。我只是为客户端请求返回一个带有唯一请求 ID 的 202 响应，并在服务器上启动一些线程来创建对象。客户端应该在将来检查请求是否完成。流程是这样的：

现在在第三步，这些事情可能会发生：

现在我的 API /my-app/<reqId> 应该针对上述三种情况响应什么 http 代码？

【问题讨论】：

【解决方案1】：

我可能会从一开始就做一些不同的事情。 Location 标头有一个specific meaning，指向连接到请求的实际资源，基本上是请求的“结果”，而不是指示请求本身状态的资源。这可能是一个很小的差异，但以后可能会令人困惑。

此外，规范says 和202 应返回指示或链接到描述请求本身进度的“状态”资源的内容。

所以流程可能是：

客户端执行POST
服务器发送202 Accepted。 Location 标头指向请求资源所在的 URI（这不是状态），这将是 404 直到处理完成。此外，202 的内容可能包括“状态”表示。 Content-Location 标头包含指向此“状态”资源的链接。
客户端GETs 状态资源检查进度。此资源始终存在，因此它始终返回 200。
如果状态指示成功，则Location 中指示的资源现在存在，否则将永远不存在。状态资源继续无限期存在。

【讨论】：

创建实际资源时出现错误怎么办？我应该在响应正文中为“状态”资源返回 200 并带有错误详细信息吗？
是的，因为“状态”总是存在的，所以那里没有错误。如果服务器上的后台创建过程出现错误，是内容表明了这一点，而不是协议本身。作为替代方案，您可以只检查请求的资源（处理结果）是否存在。如果它不存在，那将是404，并在创建时切换到带有内容的200。但是，如果发生错误，它可能永远不会被创建。
我要补充一点，添加有关何时再次检查状态资源的说明很有用，并且可能会大规模推荐，以保护自己免受答案的锤击。这可以通过基础设施（通过使用标准的最后更新或版本标头，然后缓存状态响应）来完成，或者通过在响应中设置一个说明何时再次检查的字段（即日期/时间）来完成。不过，两者都是软合规解决方案，需要客户遵守才能工作。如果您不控制客户端，您还可以使用限制策略来强制执行。