兄弟们，对于前后端联调中，对响应数据结构的定义，有没有最佳实践？

[feeeff]

目前根据我的工作经验，只能得到如下的三种情况，是否有改进空间呢？

• 正常请求响应数据

  • httpCode = 200
  • responseData

  {
  	message: "获取数据成功",
  	code: 0,
  	data: {}
  }
  

• 业务错误响应数据

  • httpCode = 200
  • responseData
  • 请求-响应链路没有问题，但是业务逻辑出错了

  {
  	message: "业务错误",
  	code: 10000,
  	data: null,
  }
  
  前后端，提前约定好 code = 10000 的具体业务含义
  

• 请求-响应过程错误响应数据

  • httpCode ≠ 200
  • responseData
  • 请求-响应链路有问题，比如接口 4XX ，5XX 了

  {
  	message: "服务错误",
  	code: 0,
  	data: null,
  }
  

[Zhuzhuchenyan]

这个应该是没有所谓的“最佳实践的”，光业务错误是否使用 HTTP 状态码就分两种流派，剩下的细分实践可以吵的点就太多了。

个人感觉这套没什么大问题，完全可以作为开始慢慢迭代，我的话会在返回 4xx ，5xx 的时候把 code 变成-1

剩下的话要思考的可能就是怎么更好约束什么是业务错误，什么是服务错误，分页逻辑用的字段定义在哪里。

[RightHand]

正常选上面，好沟通交流，如果有大佬把控全局选下边，下边可以精简数据

[wunonglin]

[wunonglin]

前端能够处理、区别正常请求和不正常请求，从而走不同的逻辑

https://developer.mozilla.org/en-US/docs/Web/API/Response/ok

从而解析是正常结构还是报错的结构

[wunonglin]

同时，例如删除接口，提交接口，90%的场景不需要返回任何东西，只需要 http 200 即可，如有其他业务需求除外，这点请分清楚。

[wunonglin]

zod 和 deepkit 等库能够解析返回的数据

1 、数据正常，那么使用库解析完后直接返回
2 、业务报错，使用库解析 body ，提示错误
3 、链路错误，使用库解析不了 body ，并且 catch 到了错误，那么提示网络错误

[lilei2023]

我们现在用的和你的差不多，请求正常都是 200 ，业务错误放在 code

[feeeff]

非常感谢各位老哥的回复

[johnhuangemc2]

我们的策略是：
只要后端能够响应，HTTP 响应码都是 200 。
响应体中使用 code 表示是否成功，message 代表给用户显示的提示内容。
code 可以定义更细致的结构，例如错误类型、模块等，以便快速定位到具体出错的模块和错误类型。

[flyqie]

个人觉得 http code 不应该掺杂业务状态。

这样能够非常快速的判断问题，并使得应用有更强的拓展性，因为 http code 给了 404 之后有些业务还得二次细分判断 app code

[prosgtsr]

我们不管 http 状态码，都是 200