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