http协议的返回状态码规范问题

假设，客户端发送了一个请求到服务器，服务器验证数据后，发觉不符合，需要返回一个错误。

我理解是，客户端由于请求过程是正确的，所以即使数据格式不符合服务端的要求，服务端也应该返回200状态码，然后在正文里带回错误信息，或一些json格式的报文，在报文里再附上真正的状态码。

但是看了一些别人的接口，有人是直接返回510状态码。

请问，各位有何高见？哪种才是规范？

回复内容：

假设，客户端发送了一个请求到服务器，服务器验证数据后，发觉不符合，需要返回一个错误。

我理解是，客户端由于请求过程是正确的，所以即使数据格式不符合服务端的要求，服务端也应该返回200状态码，然后在正文里带回错误信息，或一些json格式的报文，在报文里再附上真正的状态码。

但是看了一些别人的接口，有人是直接返回510状态码。

请问，各位有何高见？哪种才是规范？

很多网上那些接口，大多是不符合规范的，说白了就是一群连 HTTP 协议都不懂的人写的 HTTP 服务，毫无参考价值。所以不要纠结那些。为什么 PHP 招黑和这个原因类似，很感激你愿意深究这个问题，为你这种精神必须点赞。

其实我建议你购买此书：《HTTP 权威指南》，很适合你这种有上进心的人。

对于这个问题，实际上你的理解有偏差。

请求过程正确不意味着响应就应当是 200。因为能够获得响应，就已经说明请求 过程 是没有任何问题的，若是请求过程不正确，不是 DNS 异常就是连接超时等等，你连响应码都看不到的。

所以响应码是用来标识 HTTP 服务器收到请求后，对此响应给出的结果。

为此，主要 划分了 2xx、3xx、4xx、5xx 这几种，2 打头的肯定是成功（不仅仅是 200 哦），3 开头的往往是无异常，但可能资源不是直接从你这个请求获取的，比如 302 重定向，304 缓存未过期等等。

重点来了，4 打头的，往往是请求存在异常，比如你所谓的提交的数据格式不正确 400 或 422，请求需要授权的 401，因为某种原因（权限不足或者黑名单）导致的拒绝用 403，请求的数据不存在或者该数据不想被当前请求获取用 404（很熟悉吧），请求方法被拒绝用 405，比如修改数据应该用 PUT 请求、新增数据用 POST，获取数据用 GET，删除数据用 DELETE 请求等等（还有常见的 OPTIONS 和 HEAD 请求哦），当然，4 开头的响应码最多，可以在百科（不论啥百科）都有 HTTP 状态码的详细文章。

5 开头的主要是服务器错误，不是因为请求的错误引起的异常都是用 5 开头的状态码，比如 500 服务器异常、503 服务器无法提供服务。

HTTP 状态码是在 RFC 一系列标准文件中定义的，因此不能够完全适应所有的接口提示细节，但已经能够完全涵盖大部分响应的语义。对于细节提示，接口响应中往往会单独在设置一个状态响应码，用来弥补 HTTP 状态码对于细节问题的表现力不足的情况。比如都是请求格式错误，但是缺少某个参数和参数给多了，都是 400，如果想要让客户端清楚地知道发生了什么，你还需要在接口中额外定义一些东西，辅助这类情况。

这个问题其实是要结合具体应用场景。

首先，如果你的客户端是指App，尤其是手机App，使用200再加上特定错误码的形式是正确的选择！并不是这样更合理，而中国（嗯，其实国外也有）有个国情叫 HTTP 劫持。404或者500有可能直接被运营商或者其它（呵呵）劫持掉。你返回的任何附加http错误信息内容，App都将无法接收到。所以你看A厂B厂T厂的公网协议都会以这个方式来传递错误，并非设计师或者架构师不懂什么叫Restful与HTTP状态码。

如果是内部协议，服务对服务，在保证环境的情况下，你尽可以以标准的，Restful形式定义错误。

哦，分享你张图，如果你有条件且更青睐标准HTTP状态码形式的错误协议。

规范各种各样各有各的理，你说的两种状态码一种是以http请求为主参照来分析状态码，另一种是以自己接口为主参照来分析状态码。两种都有自己的理由，看使用场景吧

规范吗，还是跟着公司走~，个人比较喜欢用http状态码返回错误并带上错误信息。

你的是错误的，虽然不是200 状态码，但是其余的状态码也是可以带上相应的内容也可以有json，不知道你有没有用过spring mvc，貌似在4.xx 的时候有的这个功能，只要是用校验的都会返回400状态码，并返回json。

这个得看你们项目之中是怎么规范的的！你可以按照http的方式来，也可以自己去设置！比如说，你接受到了这个错误状态码，然后自己设置一个新的状态码，然后顺带返回一些信息提示就行了！

看需求而定,项目整体规范为准,如果你个人为项目主导,也可以你为准

参考腾讯的微信开发文档说明.
都是统一的接口返回值
http status code 基本都是200.
用不同的error_code来定义错误.

个人觉得

用http状态码才正确。

510 不了解，说个我经常写的状态码。

http status 400 和 403。

前者代表请求无法解析，一般多是参数有问题，而且多数时候这个错误是不需要写代码判断，服务器程序会自动判断并返回这个状态。

比如 我参数只允许传1-10之间的数，如果用户瞎传我就会返回这个状态码。

后者的含义是用户没有权限访问，这种错误除了部分在配置里设置的禁止访问的路径外，很多时候需要写代码进行权限判断。

比如我的后台只允许 某些特定ip和带有特定请求头的机器访问，其他机器全部返回这个状态码。

---

如果改用200 + json返回 状态码，那http这些标准的状态码的含义就基本没用。那设计者早就把他简化的只剩下200和404了。甚至404也可以用 json 状态码，只用200表示连通没连通即可。

那状态码有什么好处呢？

现代的浏览器和搜索引擎爬虫都会识别 和部分处理http状态码

举个例子：

4xx 的状态码表示当前这个url不对，没有再次发送请求的意义。
如果你某个页面返回的是 http 200 + json 400 表示 他参数有问题。

搜索引擎 不会去解析你的自定义状态码，自然会将本条数据错误的收录。
某些用户通过搜索引擎会跳转到这个参数不正确的页。

浏览器 同样不会去解析你的自定义状态码， 浏览器会自动记录你的访问记录，而浏览器接到400、403和404之类的状态码是不会保存浏览记录（chrome是这样，其他的好像也差不多吧）。

而你返回200后，用户输入网址时有很高的概率会点击浏览器的提示记录，结果又一次访问了错误的连接。