Question

我正在使用基于REST的API构建一个应用程序，并且我已经为每个请求指定了状态代码。

对于未通过验证的请求或请求尝试在我的数据库中添加副本的情况，我应该发送什么状态代码？

我看了http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html，但似乎没有一个是正确的。

发送状态代码时是否有通用做法？

Answer 1

输入验证失败：400 Bad Request +您的可选说明。这在“RESTful Web Services”一书中有所建议。双提交：409 Conflict

2014年6月更新

以前的相关规范为RFC2616，其中使用了400（错误请求），而不是

由于语法格式错误，服务器无法理解该请求

因此可能会认为它不适合语义错误。但不是更多;自2014年6月起，取代之前的RFC2616的相关标准RFC 7231更广泛地使用了400 (Bad Request)

服务器不能或由于被认为是某种东西，它不会处理请求客户端错误

Answer 2

验证失败：403 Forbidden（“服务器理解请求，但拒绝履行请求”）。与流行的观点相反，RFC2616没有说“403仅用于失败的身份验证”，但“403：我知道你想要什么，但我不会这样做”。这种情况可能是也可能不是由于身份验证。
尝试添加副本：409 Conflict（“由于与资源的当前状态发生冲突，无法完成请求。”）

您绝对应该在回复标题和/或正文中提供更详细的说明（例如，使用自定义标题 - X-Status-Reason: Validation failed）。

Answer 3

我建议status code 422, "Unprocessable Entity"。

11.2。 422不可处理的实体

422（不可处理实体）状态代码表示服务器理解请求实体的内容类型（因此415（不支持的媒体类型）状态代码不合适），并且请求实体的语法是正确的（因此400 （错误请求）状态代码不合适）但无法处理包含的指令。例如，如果XML请求主体包含格式正确（即语法正确）但语义错误的XML指令，则可能会出现此错误情况。

Answer 4

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", ...]
    }
}

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

Answer 5

数据库中的副本应为409 CONFLICT。

我建议使用422 UNPROCESSABLE ENTITY进行验证错误。

我在这里给出了4xx代码的更长解释：http://parker0phil.com/2014/10/16/REST_http_4xx_status_codes_syntax_and_sematics/

Answer 6

<强> 200

呃......（309,400,403,409,415,422）......很多答案试图猜测，争论并标准化成功的HTTP请求的最佳返回代码但失败的REST调用。

错误混合HTTP状态代码和REST状态代码。

然而，我看到许多实现混合它们，许多开发人员可能不同意我的看法。

HTTP返回代码与HTTP Request本身相关。 REST调用是使用超文本传输协议请求完成的，它的工作级别低于调用的REST方法本身。 REST是一种概念/方法，其输出是业务/逻辑结果，而HTTP结果代码是传输结果。

例如，返回＆＃34; 404 Not found＆＃34;当你打电话/用户/混淆时，因为它可能意味着：

URI错误（HTTP）
找不到用户（REST）

＆＃34; 403 Forbidden / Access Denied＆＃34;可能意味着：

需要特别许可。浏览器可以通过询问用户/密码来处理它。（HTTP）
服务器上配置的访问权限错误。（HTTP）
您需要通过身份验证（REST）

该列表可能会继续出现＆＃39; 500服务器错误＆＃34; （Apache / Nginx HTTP抛出错误或REST中的业务约束错误）或其他HTTP错误等...

从代码中，很难理解失败原因是什么，HTTP（传输）失败或REST（逻辑）失败。

如果HTTP请求在物理上成功执行，则总是返回200代码，无论是否找到记录。因为URI资源是找到并且由HTTP服务器处理。是的，它可能会返回一个空集。是否有可能收到一个空的网页，其中包含200作为HTTP结果，对吗？

除此之外，您可以返回200个带有一些选项的HTTP代码：

＆＃34;错误＆＃34;如果出现问题，JSON结果中的对象
如果未找到记录，则清空JSON数组/对象
bool结果/成功标志与之前的选项相结合，以便更好地处理。

此外，一些互联网服务提供商可能会拦截您的请求并返回404 HTTP代码。这并不意味着您的数据未找到，但在运输级别出现问题。

来自Wiki：

2004年7月，英国电信提供商BT集团部署了Cleanfeed 内容阻止系统，它向任何请求返回404错误互联网观察认定为可能违法的内容基础。其他ISP返回HTTP 403＆＃34;禁止＆＃34;同样的错误情况。用假404错误作为手段的做法泰国和突尼斯也报道了隐瞒审查制度。在突尼斯，2011年革命前审查严重，人们开始意识到假404错误的本质和创造一个名为＆＃34; Ammar 404＆＃34;谁代表＆＃34;看不见的人审查＆＃34;

为什么不简单回答这样的事情？

{
  "result": false,
  "error": {"code": 102, "message": "Validation failed: Wrong NAME."}
}

Google总是在其地理编码API中返回200作为状态代码，即使请求在逻辑上失败：https://developers.google.com/maps/documentation/geocoding/intro#StatusCodes

即使REST请求失败，Facebook也会为成功的HTTP请求返回200：https://developers.facebook.com/docs/graph-api/using-graph-api/error-handling

简单的HTTP状态代码用于HTTP请求。 REST API是您的，定义您的状态代码。

Answer 7

Ember-Data的ActiveRecord适配器期望从服务器返回422 UNPROCESSABLE ENTITY。因此，如果您的客户端是用Ember.js编写的，那么您应该使用422.只有这样DS.Errors才会填充返回的错误。适配器中的You can of course change 422 to any other code。

Answer 8

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

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

如果要将重复请求视为警告或通知而不是错误，则304未修改的响应状态代码和标识现有资源的Content-Location标头将同样有效。当意图仅仅是为了确保资源存在时，重复请求不会是错误而是确认。请求没有错，但只是冗余，客户端可以引用现有资源。

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

Answer 9

406 - Not Acceptable

这意味着当网络服务器在执行服务器驱动的内容协商后，未找到符合用户代理给出的条件的任何内容时，发送此响应。

REST HTTP状态代码，用于验证失败或重复无效

9 个答案:

406 - Not Acceptable