在这种情况下使用代码424是否正确?
对于这个问题,肯定有一些不同的意见。RFC4918定义了HTTP状态码424为(重点在于):
状态码424(Failed Dependency)表示请求不能完成,因为请求的操作依赖于其他操作,而其他操作失败了。例如,如果PROPPATCH方法中的一个命令失败,则至少会出现424(Failed Dependency)错误,并导致其余的命令也无法执行。
在我的看法中,这种情况并不适用,因为相关操作尚未发生,而该状态码似乎表明相关操作已经接收但失败了。
Julian Rechke的答案是409 Conflict,在RFC2616中定义为:
由于与资源的当前状态存在冲突,无法完成请求。只有当预计用户可能能够解决冲突并重新提交请求时,才允许使用此代码。响应正文应包含足够的信息,以便用户识别冲突的源头。理想情况下,响应实体包含足够的信息,供用户或用户代理修复问题;但可能无法实现,并且不是必需的。
然而,如果接收到此响应的客户端能够解决问题(在本例中是创建父级对象),则应使用此响应。如果无法解决问题,我可能会建议使用422 Unprocessable Entity,同样来自RFC4918:
或者只返回一个传统的400 Bad Request错误,因为在请求时创建不存在父级的子节点不是很合理。状态码422(Unprocessable Entity)表示服务器能够理解请求实体的内容类型(因此不适用415(Unsupported Media Type)状态码),并且请求实体的语法正确(因此不适用400(Bad Request)状态码),但无法处理包含的指令。例如,如果XML请求正文包含语法正确但语义上错误的XML指令,则可能会出现此错误条件。
我个人认为你应该这样做,问题在于这个状态码有多么出名。我不得不先去维基百科查一下。
然而,即使客户端默认不处理此代码,也很容易猜到这是客户端错误。
如果可能的话,我会添加一个提示,说明缺少了哪个调用。
424 在 WebDAV 中有定义;这并不是问题,但是 WebDAV 用于描述错误情况的状态码是 409(冲突)。这是我会使用的。