时间:2021-07-01 10:21:17 帮助过:19人阅读
我理解是,客户端由于请求过程是正确的,所以即使数据格式不符合服务端的要求,服务端也应该返回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来定义错误.
个人觉得
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后,用户输入网址时有很高的概率会点击浏览器的提示记录,结果又一次访问了错误的连接。