当一个请求需要先完成另一个请求时，我能否使用HTTP响应状态码424？

Question

例如，我有一个实体层次结构，由于某些问题，我收到了在创建父级请求之前创建子级的请求。

在这种情况下使用代码424是否正确？

- Andrey Shchekin

Answer 1

对于这个问题，肯定有一些不同的意见。RFC4918定义了HTTP状态码424为（重点在于）：

状态码424（Failed Dependency）表示请求不能完成，因为请求的操作依赖于其他操作，而其他操作失败了。例如，如果PROPPATCH方法中的一个命令失败，则至少会出现424（Failed Dependency）错误，并导致其余的命令也无法执行。

在我的看法中，这种情况并不适用，因为相关操作尚未发生，而该状态码似乎表明相关操作已经接收但失败了。

Julian Rechke的答案是409 Conflict，在RFC2616中定义为：

由于与资源的当前状态存在冲突，无法完成请求。只有当预计用户可能能够解决冲突并重新提交请求时，才允许使用此代码。响应正文应包含足够的信息，以便用户识别冲突的源头。理想情况下，响应实体包含足够的信息，供用户或用户代理修复问题；但可能无法实现，并且不是必需的。

然而，如果接收到此响应的客户端能够解决问题（在本例中是创建父级对象），则应使用此响应。如果无法解决问题，我可能会建议使用422 Unprocessable Entity，同样来自RFC4918：

状态码422（Unprocessable Entity）表示服务器能够理解请求实体的内容类型（因此不适用415(Unsupported Media Type)状态码），并且请求实体的语法正确（因此不适用400(Bad Request)状态码），但无法处理包含的指令。例如，如果XML请求正文包含语法正确但语义上错误的XML指令，则可能会出现此错误条件。

或者只返回一个传统的400 Bad Request错误，因为在请求时创建不存在父级的子节点不是很合理。

- Ross Taylor-Turner

---

我认为你给出了最详细的答案。唯一我正式不同意的是使用400 Bad Request -- 我觉得它不适用于格式良好但逻辑上无效的请求，例如http://tools.ietf.org/html/rfc5789#section-2.2支持我使用422。 - Andrey Shchekin

最终，我决定在我的情况下使用424，尽管我同意在形式上它可能有些不受支持（依赖请求没有失败）。然而如果它失败了，结果也是一样的 - 所以我觉得这种做法是有意义的。 - Andrey Shchekin

Answer 2

我个人认为你应该这样做，问题在于这个状态码有多么出名。我不得不先去维基百科查一下。

然而，即使客户端默认不处理此代码，也很容易猜到这是客户端错误。

如果可能的话，我会添加一个提示，说明缺少了哪个调用。

- rekire

Answer 3

424 在 WebDAV 中有定义；这并不是问题，但是 WebDAV 用于描述错误情况的状态码是 409（冲突）。这是我会使用的。

- Julian Reschke