欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  后端开发

http status code的使用问题

程序员文章站 2022-06-06 20:17:28
...
作为一个前端,最近开始写后台,遇到了一些restful设计上的问题,希望各位大神解答一下。
restful规范特别的强调了HTTP Status Codes的使用,但是我在使用的时候却有一些疑惑。尤其是在返回错误信息这块。
我自己使用时是约定好一套关于业务的错误码,比如20001,代表'缺少xxx字段',把他放在http response body里面返回,然后在response头里面写好200 OK之类的。
比如login的时候,假如前端传过来的json里面没有password字段,
那我返回一个400 Bad Request的http报文,同时报文的body部分如下(仅仅举个例子哈,一切从简):
{
"code":20001,
"message":"缺少password字段"
}

对于上面这样的处理方式,主要的疑问点在于:
有的时候的业务上的错误不知道该用哪个HTTP Status Codes,比如说新建用户,如果说用户名已存在,那我这个时候body部分很好搞,但是HTTP Status Codes应该用哪个呢?400 Bad Request肯定不对吧,人家前端传过来的信息没有问题,401 Unauthorized 403 Forbidden之类的感觉也不能用在这,所以这个时候的HTTP Status Codes状态码到底应该用什么呢?
确实有很多同学在使用时是不管什么情况都返回200 OK,然后在http body部分用json去返回错误信息,但我还是觉得HTTP Status Codes是restful中很重要的一部分,restful规范也很强调对其的使用,所以我还是希望大家给我指条明路,这部分到底该怎么弄。

回复内容:

作为一个前端,最近开始写后台,遇到了一些restful设计上的问题,希望各位大神解答一下。
restful规范特别的强调了HTTP Status Codes的使用,但是我在使用的时候却有一些疑惑。尤其是在返回错误信息这块。
我自己使用时是约定好一套关于业务的错误码,比如20001,代表'缺少xxx字段',把他放在http response body里面返回,然后在response头里面写好200 OK之类的。
比如login的时候,假如前端传过来的json里面没有password字段,
那我返回一个400 Bad Request的http报文,同时报文的body部分如下(仅仅举个例子哈,一切从简):

{
"code":20001,
"message":"缺少password字段"
}

对于上面这样的处理方式,主要的疑问点在于:
有的时候的业务上的错误不知道该用哪个HTTP Status Codes,比如说新建用户,如果说用户名已存在,那我这个时候body部分很好搞,但是HTTP Status Codes应该用哪个呢?400 Bad Request肯定不对吧,人家前端传过来的信息没有问题,401 Unauthorized 403 Forbidden之类的感觉也不能用在这,所以这个时候的HTTP Status Codes状态码到底应该用什么呢?
确实有很多同学在使用时是不管什么情况都返回200 OK,然后在http body部分用json去返回错误信息,但我还是觉得HTTP Status Codes是restful中很重要的一部分,restful规范也很强调对其的使用,所以我还是希望大家给我指条明路,这部分到底该怎么弄。

建议看一下http status code列表,4xx的响应码还是很多的,一般4xx也是代表是请求错误。

规范只是大体建议,按照规范来可以,你搞个233 ok也行,关键是协调好,留下相关文档...

假设是在网站型的程序中使用,网站说白了是给用户看的,诚然网页不存在要返回404,但是这个功能web服务器一般会帮我们做,不过单纯的在出错的时候使用一个服务器给出的默认页面是不够的,网站是给人看的,用户才不管你返回码设置的有多科学,你就是把返回码玩出花来,他们也不买你的帐。所以说,对于网站来说,可以给出常用的返回码,但是重点在于展示的页面。至于是不是返回码是400 401之类的,你做再讲究不如一个出错信息提示页来的简洁明快。

对于API型的应用来说,假设这个API是给前端ajax用的,如果你在业务逻辑出错的时候给出了一个HTTP协议的状态码,那么它只会在控制台上打印一条错误日志。如果你用的是jquery来处理的ajax,那么它就会触发error函数回调,这肯定不是你想要的,正常的做法是返回json数据,这个json中带有返回码和错误信息,在出错的时候将json中的错误信息字段显示出来。如果你在出错时用返回码,则在error回调中还拿不到具体的错误原因,你只能显示一个模糊的信息,操作xxx出错了,这肯定不是用户想要的,这同时增加了客服的难度,用户再跟客服描述的时候只能描述一个模糊的问题。当然还有一个隐藏的问题,假设你使用了反向代理,前端程序也没法区分当前的非法的返回码到底是web应用程序返回的,还是反向代理服务器返回的。

假设你在纯服务器之间的API之间使用自定义HTTP返回码,你会发现开发者仅仅解析一个HTTP返回码是不够的,他们想知道错误的详细信息,这时候你还得返回一个json数据。当然上面说的反向代理的问题,在这里依然存在。

所以综上所述,我是不推荐使用自定义HTTP返回码的,虽然它很科学,但是它太学究,不实用。特别对于网站应用程序遇到链接找不到或者未捕获异常,才返回404或者500,而且返回的时候要使用友好的出错页来承载,其他逻辑错误也尽量使用错误页来承载。

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。

感觉这个合适唉

422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。

这个提示也不错

有冲突信息的话也可以使用 409 Conflict

这边HTTP状态码解析可以看下
http://jingyan.baidu.com/arti...

相关标签: restful node php