想给所有的业务异常一个统一固定的 HTTP 状态码,用什么合适? 403? 409? 422?

查看 152|回复 13
作者:param   
http 状态码能不能用-1 的。
不要 200 ,那样我就要在 response 再包一层。
我想给业务异常统一固定的 HTTP 状态码,例如 403 ,那么我遇到 403 才会拆开看里面的业务异常,在 403 的 response 里返回大写字母格式的错误码以及 err msg 。如果遇到 200 ,就默认没有异常,不需要拆开了。
业务异常指的是,诸如「未完成的订单不允许评论」之类的
403 经常被认为是「权限不够,换个身份操作就可以成功」的意思,但它其实应该是「 forbidden 」,没有说明是权限不够而 forbidden ,或者其他原因的 forbidden 。具体原因还是可以在 body 里看。
这个问题在这里好像吵得很厉害,我不想对 200 再封一层,同时也需要自定义的状态码,这完全不矛盾呀。

response, 拆开, 异常, msg

dzdh   
非要定一个比较合理的规范的话。可以考虑 guzzle 的封装
由于提交的参数有问题的 4xx
- 资源不存在( id?=x ) 404
- 缺少参数,参数不合法 400
- 不能操作这个资源 (?id=xx ) 403
class X extends Exception {}
class X404 extends X{}
class X400 extends X{}
class ResourceNotFound extends X404 {}
param
OP
  
@dzdh 如果要细分的话,很容易选择困难。。所以业务层的异常还是统一同一个码就好了。
otakustay   
毫无疑问的 400 吧
dzdh   
@param
我是统一 200 code, result, mark, data :doge:
xfn   
我的理解是如果是调用方的问题返回 4xx ;服务提供方的问题返回 5xx ;你这种情况应该是调用方没有满足业务期望的条件,个人认为 400 比较合适
mritd   
感觉应该 400 好点吧, 不过确实很多业务系统喜欢 200 all in... 他们却是也有一些理由, 就是某些 http 库非 200 可能抛 异常啥的; 不过我没写过客户端还是不太了解, 我个人理解 HTTP CODE 应该是更高层次的、笼统一点的错误提示, 而内部 body 可以附加业务层次的特定错误描述.
param
OP
  
@otakustay 请求格式错误才是 400 吧,例如本该用 application/json 的却用了 multipart/form-data
otakustay   
@param #7 所有客户端的错误都是 400 ,请求格式错误 415
fredweili   
除了 code ,还能再传一个 header
您需要登录后才可以回帖 登录 | 立即注册

返回顶部