最近我们公司开发一个项目, 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:{}}
|  |      1bdbai      2016-08-05 18:51:55 +08:00 via Android 可以参考 REST 。 个人偏好版本 1 ,毕竟 HTTP 状态码已经有语义了。 | 
|  |      2abelyao      2016-08-05 22:14:33 +08:00 via iPhone 实践下来发现, http 的状态是反映网络情况的,自定义状态是反映业务处理结果的,搞混了在客户端不好处理,最后还是分开了。 也可能是我 REST 没玩熟 | 
|  |      4abelyao      2016-08-06 00:00:39 +08:00 @bdbai 网络有问题收到 http 的状态码,例如 408 请求超时,对于这些 http 类的错误状态,可以把 http 请求做一个封装,对 response error 做个统一处理,这部分我觉得和业务错误是要区分开的。 | 
|      6pljhonglu      2016-11-18 14:15:18 +08:00 内部使用,两种都可以。 对外提供 API ,通常 RESTAPI 。 实际操作中,项目开始时跟后端沟通接口,都倾向于把业务状态放到 body 中。主要考虑应该是可以套用现有的代码逻辑,不需要做太多修改。而且对于前端来说,两种方式处理起来其实并没有太大的区别,所以也没必要非得搞得那么清真~ |