最好在一套系统中,甚至一个团队,一个公司中都遵循一套返回状态码规则,并提前做好规划,比如:
0001 ~ 1999 ,2000 ~ 2999,4000 ~ 4999
这些码段可以按:业务类型,按功类型,按架构层面提前规划好,比如x~y是网络段的,哪段用于错误码,哪段用于成功码,感觉这样从架构层面上来分比较清晰,一下子就知道是成功还是失败了,然后根据其它位上的数还可以识别出业务层上面的特征,感觉这几种规划组合起来有最好的效果,给出码段。这样整体规划就能达到统一了。
ABCD四位
A:?
B:?
C:?
D:?
比较成熟的系统,比如微信,一些软件,网站在各种情况,或者各种出错时都会有一个返回状态码,我知道这个状态码每个业务都有,一个系统中业务那么多,肯定有一个好的返回码设计规范的。
想请问一下大家一般这种规范怎么设计呢,遵循什么标准呢,哪儿可以找到参考的资料呢?
(我记得以前哪儿看到过美团外卖的接口返回码设计标准,现在忘记了找不到了)
个人认为,大型应用体系中的错误码应该是少数的,就像RESTful设计HTTP接口那样,常用的错误码不到10个,其详细的错误内容直接以错误信息的方式显示,不是使用错误码来定义。设计详细的错误码也是为了判断错误的,与其遇见错误时根据错误码再去查错误码表找到错误信息,不如直接传错误信息。
一周热门 更多>