设计 API 接口返回的 JSON 数据格式有没有比较流行的最佳实践？

[system]

最近我们公司开发一个项目， PC 端 手机 APP 端 手机网页端 设计 API 接口返回的 JSON 数据格式有没有比较流行的最佳实践？

目前找了以下几种版本

版本 1 ： 成功执行： head Status Code:2XX

json {"id":51,"age":58,"name":"lifei"}

失败执行 head Status Code:4XX-5XX {"message":"xxxxxx 错误","errors:{}}

版本 2 ： 成功和失败执行 head Status Code:2xx

json {"code":"0","message:"信息","data":{}}

版本 3: 成功执行： head Status Code:2XX

json {"id":51,"age":58,"name":"lifei"}

失败执行 head Status Code:4XX-5XX {"code":10001, "message":"xxxxxx 错误","errors:{}}

[bdbai]

可以参考 REST 。
个人偏好版本 1 ，毕竟 HTTP 状态码已经有语义了。

[abelyao]

实践下来发现， http 的状态是反映网络情况的，自定义状态是反映业务处理结果的，搞混了在客户端不好处理，最后还是分开了。

也可能是我 REST 没玩熟

[bdbai]

@abelyao 如果网络有问题的话，状态码也收不到了吧

[abelyao]

@bdbai 网络有问题收到 http 的状态码，例如 408 请求超时，对于这些 http 类的错误状态，可以把 http 请求做一个封装，对 response error 做个统一处理，这部分我觉得和业务错误是要区分开的。

[bdbai]

@abelyao 这样的话约定好错误定义也不赖，很多网站也是这么做的。

[pljhonglu]

内部使用，两种都可以。
对外提供 API ，通常 RESTAPI 。

实际操作中，项目开始时跟后端沟通接口，都倾向于把业务状态放到 body 中。主要考虑应该是可以套用现有的代码逻辑，不需要做太多修改。而且对于前端来说，两种方式处理起来其实并没有太大的区别，所以也没必要非得搞得那么清真~