验证失败或重复无效的REST HTTP状态代码

本文翻译自：REST HTTP status codes for failed validation or invalid duplicate

I'm building an application with a REST-based API and have come to the point where i'm specifying status codes for each requests. 我正在使用基于REST的API构建应用程序，并且到了我为每个请求指定状态代码的地步。

What status code should i send for requests failing validation or where a request is trying to add a duplicate in my database? 对于验证失败的请求，或者请求试图在数据库中添加重复项的情况，我应该发送什么状态代码？

I've looked through http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html but none of them seems right. 我已经浏览了http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html，但是似乎都不对。

Is there a common practice when sending status codes? 发送状态代码时是否有惯例？

---

#1楼

参考：https://stackoom.com/question/DnvS/验证失败或重复无效的REST-HTTP状态代码

---

#2楼

200,300, 400, 500 are all very generic. 200,300、400、500都是非常通用的。 If you want generic, 400 is OK. 如果要通用，则400即可。

422 is used by an increasing number of APIs, and is even used by Rails out of the box. 422被越来越多的API使用，甚至被Rails开箱即用。

No matter which status code you pick for your API, someone will disagree. 无论您为API选择哪种状态代码，都会有人不同意。 But I prefer 422 because I think of '400 + text status' as too generic. 但是我更喜欢422，因为我认为“ 400 +文本状态”过于笼统。 Also, you aren't taking advantage of a JSON-ready parser; 另外，您没有利用JSON就绪的解析器； in contrast, a 422 with a JSON response is very explicit, and a great deal of error information can be conveyed. 相反，带有JSON响应的422非常明确，并且可以传达大量错误信息。

Speaking of JSON response, I tend to standardize on the Rails error response for this case, which is: 说到JSON响应，我倾向于针对这种情况对Rails错误响应进行标准化，即：

{
    "errors" :
    { 
        "arg1" : ["error msg 1", "error msg 2", ...]
        "arg2" : ["error msg 1", "error msg 2", ...]
    }
}

This format is perfect for form validation, which I consider the most complex case to support in terms of 'error reporting richness'. 这种格式非常适合表单验证，就“错误报告丰富性”而言，我认为这是最复杂的情​​况。 If your error structure is this, it will likely handle all your error reporting needs. 如果您的错误结构是这样，它将可能满足您所有的错误报告需求。

---

#3楼

Status Code 304 Not Modified would also make an acceptable response to a duplicate request. 状态代码304未修改也会对重复的请求做出可接受的响应。 This is similar to processing a header of If-None-Match using an entity tag. 这类似于使用实体标签处理If-None-Match的标头。

In my opinion, @Piskvor's answer is the more obvious choice to what I perceive is the intent of the original question, but I have an alternative that is also relevant. 我认为，@ Piskvor的答案是最明显的选择，我认为这是原始问题的意图，但是我有一个也很相关的选择。

If you want to treat a duplicate request as a warning or notification rather than as an error, a response status code of 304 Not Modified and Content-Location header identifying the existing resource would be just as valid. 如果要将重复的请求视为警告或通知，而不是错误，则响应状态代码304未修改和标识现有资源的Content-Location标头将同样有效。 When the intent is merely to ensure that a resource exists, a duplicate request would not be an error but a confirmation. 当只是为了确保资源存在时，重复的请求不是错误而是确认。 The request is not wrong, but is simply redundant, and the client can refer to the existing resource. 该请求没有错，但只是多余的，客户端可以引用现有资源。

In other words, the request is good, but since the resource already exists, the server does not need to perform any further processing. 换句话说，请求是好的，但是由于资源已经存在，因此服务器不需要执行任何进一步的处理。

---

#4楼

A duplicate in the database should be a 409 CONFLICT . 数据库中的重复项应为409 CONFLICT 。

I recommend using 422 UNPROCESSABLE ENTITY for validation errors. 我建议对验证错误使用422 UNPROCESSABLE ENTITY 。

I give a longer explanation of 4xx codes here: http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/ 我在这里给出了4xx代码的详细说明： http : //parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

---

#5楼

Ember-Data's ActiveRecord adapter expects 422 UNPROCESSABLE ENTITY to be returned from server. Ember-Data的ActiveRecord适配器期望从服务器返回422 UNPROCESSABLE ENTITY 。 So, if you're client is written in Ember.js you should use 422. Only then DS.Errors will be populated with returned errors. 因此，如果您的客户端使用Ember.js编写，则应使用422。只有这样，DS.Errors才会填充返回的错误。 You can of course change 422 to any other code in your adapter. 您当然可以将422更改为适配器中的任何其他代码 。

---

#6楼

For input validation failure: 400 Bad Request + your optional description. 对于输入验证失败： 400错误的请求 +您的可选描述。 This is suggested in the book " RESTful Web Services ". 在“ RESTful Web服务 ”一书中建议这样做。 For double submit: 409 Conflict 对于双重提交： 409冲突

---

Update June 2014 2014年6月更新

The relevant specification used to be RFC2616 , which gave the use of 400 (Bad Request) rather narrowly as 相关的规范曾经是RFC2616 ，它给出了400（错误请求）的使用范围，

The request could not be understood by the server due to malformed syntax 由于语法格式错误，服务器无法理解该请求

So it might have been argued that it was inappropriate for semantic errors. 因此， 可能有人认为它不适合语义错误。 But not any more; 但是没有更多了。 since June 2014 the relevant standard RFC 7231 , which supersedes the previous RFC2616, gives the use of 400 (Bad Request) more broadly as 自2014年6月起，相关标准RFC 7231 （取代了先前的RFC2616 ）在以下方面更广泛地使用了400（错误请求） ：

the server cannot or will not process the request due to something that is perceived to be a client error 由于某些原因，服务器无法或将不会处理请求，因为这被视为客户端错误