POST请求返回HTTP状态码404可以吗？

Question

我正在开发一个API，我始终尝试为每个情况使用最正确的http状态码。

其中一个情况是针对POST请求的响应。例如，/orders/ 端点的POST方法将接收一些信息，如customer：

{
  customerDocument: {number: "123.456.789"},
  // other informations for create a order
}

所以，我的问题是：如果客户文档中的这个数字不存在，返回一个带有友好消息的404状态码错误是否可以？告诉用户未找到该客户。

通常我只在特定资源的GET请求中使用404（最显然的用法），例如：

/customers/{number}/

在业务验证中，例如“客户未激活”，我通常使用HTTP状态码422，适用于任何HTTP方法（POST、PUT、GET等）。但是我对于我的POST示例是否可以使用404或422有疑问。

- Dherik

---

我倾向于遵循这个表格：http://www.restapitutorial.com/lessons/httpmethods.html - Nkosi

Answer 1

我认为在这种情况下，根据维基百科的定义，400是适当的状态码：

400 Bad Request

由于明显的客户端错误，服务器无法或不会处理请求。

根据说明，从语义上讲，422更好（“请求格式正确，但由于语义错误而无法执行。”）。然而，422是为WebDAV引入的，因此最好使用通用状态码，如400。 400并不是完美的状态码，因为文档编号是否存在或有效并不是那么明显。但是，除了422这样的特殊目的状态码之外，400是最好的选择。 为什么404不合适？ 根据RESTful API的观点，无论/orders/接受GET、POST或其他操作，它都是一个资源。只有当该资源/orders/本身不存在时，404才是适当的响应状态码。如果/orders/端点存在，但调用失败（无论原因如何），响应状态码必须是404以外的其他值。

- shaochuancs

---

除非客户端在标头中定义了先决条件，否则“412 Precondition Failed”不合适。您应该删除答案中的这部分内容。 - VoiceOfUnreason

@VoiceOfUnreason 感谢您的建议，引入 412 会使事情变得复杂和混乱。我将从我的答案中删除它。 - shaochuancs

@shaochuancs 关于404，我同意！但400似乎不是最好的选择。通常，人们会将400理解为请求中的语法或类型错误。正如维基百科链接中所描述的：“例如，请求语法错误、大小超过限制、无效的请求消息框架或欺骗性请求路由”。在RestEasy框架中，例如这些情况就使用了400。 - Dherik

@Dherik 是的，400并不完美。但在检查了所有响应代码后，我找不到比它更好的代码了。 - shaochuancs

你好，关于404错误的评论是不正确的。如果端点/orders不存在，则会出现404错误，这一部分是正确的，但是如果订单123不存在并且用户调用/orders/123，那也是404错误。@Dherik应该为他所询问的情况返回404响应。 - damian