
目前根据我的工作经验,只能得到如下的三种情况,是否有改进空间呢?
正常请求响应数据
{ message: "获取数据成功", code: 0, data: {} } 业务错误响应数据
{ message: "业务错误", code: 10000, data: null, } 前后端,提前约定好 code = 10000 的具体业务含义 请求-响应过程错误响应数据
{ message: "服务错误", code: 0, data: null, } 1 Zhuzhuchenyan 2024 年 2 月 28 日 这个应该是没有所谓的“最佳实践的”,光业务错误是否使用 HTTP 状态码就分两种流派,剩下的细分实践可以吵的点就太多了。 个人感觉这套没什么大问题,完全可以作为开始慢慢迭代,我的话会在返回 4xx ,5xx 的时候把 code 变成-1 剩下的话要思考的可能就是怎么更好约束什么是业务错误,什么是服务错误,分页逻辑用的字段定义在哪里。 |
2 RightHand 正常选上面,好沟通交流,如果有大佬把控全局选下边,下边可以精简数据 |
3 shakaraka PRO |
4 shakaraka PRO 前端能够处理、区别正常请求和不正常请求,从而走不同的逻辑 https://developer.mozilla.org/en-US/docs/Web/API/Response/ok 从而解析是正常结构还是报错的结构 |
5 shakaraka PRO 同时,例如删除接口,提交接口,90%的场景不需要返回任何东西,只需要 http 200 即可,如有其他业务需求除外,这点请分清楚。 |
6 shakaraka PRO zod 和 deepkit 等库能够解析返回的数据 1 、数据正常,那么使用库解析完后直接返回 2 、业务报错,使用库解析 body ,提示错误 3 、链路错误,使用库解析不了 body ,并且 catch 到了错误,那么提示网络错误 |
7 lilei2023 2024 年 2 月 28 日 我们现在用的和你的差不多,请求正常都是 200 ,业务错误放在 code |
8 feeeff OP 非常感谢各位老哥的回复 |
9 johnhuangemc2 2024 年 2 月 28 日 我们的策略是: 只要后端能够响应,HTTP 响应码都是 200 。 响应体中使用 code 表示是否成功,message 代表给用户显示的提示内容。 code 可以定义更细致的结构,例如错误类型、模块等,以便快速定位到具体出错的模块和错误类型。 |
10 flyqie 2024 年 2 月 28 日 via Android 个人觉得 http code 不应该掺杂业务状态。 这样能够非常快速的判断问题,并使得应用有更强的拓展性,因为 http code 给了 404 之后有些业务还得二次细分判断 app code |
11 prosgtsr 2024 年 2 月 28 日 我们不管 http 状态码,都是 200 |