最适合“正在进行的作业”的 HTTP 状态代码

Question

向客户端提供的最合适的 HTTP 状态代码是什么，表示“您的请求很好，但仍在进行中；请稍后在同一位置检查。”

例如，假设客户端提交初始请求以启动繁重的查询，服务器立即返回一个 URL，客户端可以定期轮询该 URL 以获取结果。如果客户端在作业完成之前调用此 URL，则返回最合适的 HTTP 状态代码是什么？

202 接受 将是我的第一冲动。这是最好的一个，还是有更好的一个，在 REST 接口中更适合此目的？

Answer 1

对我来说，202 已接受将是最好的选择。

请参阅 W3C 网站上的文档。

10.2.3 202 已接受

请求已被接受处理，但处理已完成 尚未完成。该请求最终可能会或可能不会被执行 上，因为在实际进行处理时可能不允许这样做。 没有从异步重新发送状态代码的工具 像这样的操作。

202回复是有意不置可否。其目的是 允许服务器接受其他进程的请求（也许是 面向批处理的过程，每天仅运行一次），无需 要求用户代理与服务器的连接持续到 该过程已完成。通过此响应返回的实体 应包括请求当前状态的指示以及 要么是一个指向状态监视器的指针，要么是用户何时使用的一些估计 可以期望请求得到满足。

Answer 2

我目前正在解决类似的问题。我有一个如下所示的 API：

POST /jobs               # Creates a job
GET /jobs/{jobId}        # Gets a job
GET /jobs/{jobId}/output # Gets job output

我的 API 流程如下所示：

POST /jobs               -> 202 Accepted, Link header to created object
GET /jobs/{jobId}        -> 200 OK, includes status field
GET /jobs/{jobId}/output -> 200 OK if job completed successfully, XXX otherwise?

因此

POST /jobs

在创建作业时返回

202

，用户轮询

GET /jobs/{jobId}

来检查状态，并使用

/jobs/{jobId}/output

来获取结果。这是我着陆的地方：

• 如果作业成功完成，则

  200 OK

  ，如上图
• 如果作业完成失败，则

  409 Conflict

• 如果作业正在处理，则

  204 No Content

  或

  425 Too Early

  ，具体取决于我是否决定不轮询

  GET /jobs/{jobId}

  和等待分别是有效的用户行为还是客户端错误。我知道

  425

  从技术上讲是一个协议级错误，但它看起来是最接近我的。

我喜欢 HATEOAS 作为一个设计概念，但感觉我们在它完全可用之前缺少了一些重要的 HTTP 代码和/或指导。