状态代码304 Not Modified也会对重复的请求做出可接受的响应。这类似于使用实体标记处理If-None-Match的报头。

在我看来，@Piskvor的答案是更明显的选择，我认为是原始问题的意图，但我有一个替代方案，也是相关的。

如果希望将重复请求视为警告或通知，而不是错误，响应状态码304 Not Modified和标识现有资源的Content-Location头同样有效。当意图仅仅是确保资源存在时，重复的请求将不是错误，而是确认。请求并不是错误的，只是多余的，客户端可以引用现有的资源。

换句话说，请求是好的，但是由于资源已经存在，服务器不需要执行任何进一步的处理。

Ember-Data的ActiveRecord适配器期望从服务器返回422个UNPROCESSABLE ENTITY。所以，如果你的客户端是用Ember.js编写的，你应该使用422。只有这样DS。错误将用返回的错误填充。当然，您可以将422更改为适配器中的任何其他代码。

数据库中的副本应该是409冲突。

我建议使用422 UNPROCESSABLE ENTITY来处理验证错误。

我在这里对4xx代码做了更详细的解释。

验证失败:403禁止(“服务器理解请求，但拒绝完成它”)。与流行的观点相反，RFC2616并没有说“403仅用于失败的身份验证”，而是说“403:我知道您想要什么，但我不会那样做”。这种情况可能是由于身份验证，也可能不是。 试图添加副本:409冲突(“由于与资源的当前状态冲突，请求无法完成。”)

你应该在响应头和/或正文中给出更详细的解释(例如，使用自定义头- X-Status-Reason: Validation failed)。

我推荐状态码422，"不可处理实体"

11.2. 422 Unprocessable Entity The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.

200,300,400,500都是很通用的。如果你想要普通的，400就可以了。

422被越来越多的api使用，甚至被开箱即用的Rails使用。

无论您为API选择哪种状态代码，总会有人不同意。但我更喜欢422，因为我认为“400 +文本状态”太一般了。此外，您没有利用json就绪的解析器;相比之下，带有JSON响应的422非常显式，可以传递大量错误信息。

说到JSON响应，我倾向于在这种情况下对Rails错误响应进行标准化，即:

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

这种格式非常适合表单验证，我认为就“错误报告丰富度”而言，表单验证是最复杂的情况。如果您的错误结构是这样的，那么它可能会处理您所有的错误报告需求。