来源:麦叔编程
作者:麦叔
代码评审会上,气氛有点紧张!
罗老师正在看张三的代码,并指出了一个问题:
你这个API,在用户没登录的情况下,应该返回401,不应该返回200。要遵守HTTP协议的规范。
张三对此不以为然的说:
我们约定了都返回200的,具体的错误信息放在返回的JSON里。我又没有违法,不能为了规范而规范吧。
罗老师竟无言以对。他赶快去查看Facebook,谷歌等业界大亨的做法,可是他们的做法也不统一。到底要不要遵守HTTP Status Code呢?
听我细细道来,本文涵盖:
你很可能已经熟悉HTTP和Restful API。不管你是否熟悉,让我们用1分钟的时间来简单回顾一下:
HTTP协议定义了浏览器和网页服务器之间的交互过程。它的核心概念就2个:
有了标准的协议就好办了,任何人都可以开发浏览器出来,只要你写的软件都能遵守这个协议就行。我记得我研究生时候一门课的大作业就是开发一个简易的浏览器。
控制了浏览器,就控制了网络流量,就不怕没钱赚了,所以各大厂商都在努力推广自己的浏览器,就有了IE, Edge,Chrome,FireFox,QQ浏览器,以及360浏览器等。有的浏览器又好用又文明,有的浏览器很流氓,有的浏览器不遵守协议,让开发人员恨得牙根痒痒。
Rest API说白了就是一个网页地址,不过它只返回JSON或者XML格式的数据,而不是HTML网页。
每个HTTP的Response都包含一个Status Code,表示请求的状态,是成功,还是失败,失败的原因是什么等等。
HTTP的Status Code一共有几十个,详细列表可以查看相关标准。但绝大部分人平时只会接触到最常见的少于10个的代码:
代码 |
含义 |
说明 |
200 |
请求成功 |
|
201 |
创建成功 |
专门用于创建新的记录的时候 |
301 |
永久重定向 |
网址永久变更成另外一个网址 |
302 |
临时重定向 |
网址临时变更成另外一个网址 |
400 |
无效的请求 |
请求的网址无效等 |
401 |
没有登录 |
需要登录才能访问 |
403 |
没有权限 |
虽然登陆了,但是没有权限 |
404 |
请求资源不存在 |
请求的东西不存在,比如某个人的信息 |
500 |
服务器端错误 |
服务器端发生了错误 |
有了这套标准,处理请求的程序首先根据状态码判定请求是否成功,然后做相应的处理。
Rest API理论上也应该遵守HTTP的规定,根据不同的情况,返回相应的状态码。但理论只是理论,大家对此的认识是不同的。基本上分成了两派:
这两派都有重量级的公司参与,比如FaceBook就是200派,而Google, Twilio等是正规派:
200派的理由很简单:反正我都需要处理返回的JSON,干脆我就把具体状态写在JSON里面,就不用管HTTP的状态码了,都用200好了。你看Facebook这样的大公司都用200了。
而正规派的人的理由就显得略微有点不正规,大部分人说:因为这是规范。Rest API是基于HTTP的,就应该遵守HTTP的状态码。
我是正规派的人,但我也觉得上面的理由有点薄弱。到底有什么好处?在什么情况下有好处?拿点实实在在的好处或者理由来?
首先,这肯定不是一个非黑即白的问题,200派和正规派都是可行的。只要API的提供者和请求者协调好,都不会带来很大的问题。但是我们仍然应该适度遵守HTTP的状态码。实实在在的理由如下:
使用了HTTP状态码以后,让API符合了一定的标准,这很好。但HTTP状态码不能涵盖我们具体的业务场景,我们仍然需要定义和业务场景相对应的错误码。下面我推荐一个错误处理的返回格式,举例如下:
{ "status":403,
"error": {
"code":'40041',
"message":"用户缺少访问特工名单权限",
"moreInfo":"https://maishucode.com/errors/40041",
"traceId":"9527" },
"data":{
}
}
下面是对每个字段的解释:
我要说的说完了!虽然这没有绝对的对错,但是符合良好的规范,提供充分的信息给调用用肯定是没错的。你觉得呢?在留言区留下你的意见吧!
数据分析咨询请扫描二维码