一种建议的接口返回结构
1 / 8 / 创建于 2年前 /
Junwind 的个人博客
比如建议如下
{
"state": {
"code": 0,
"msg": "success"
},
"data": {
"list": [ // 这里多一层 list 是有好处的
{
"id": "xx",
"prefix": "xx",
"name": "xx",
"type": "2",
...
},
...
]
}
}为什么上面的返回，要多加一层 list ? 而不是这样返回
{
"state": {
"code": 0,
"msg": "success"
},
"data": [
{
"id": "xx",
"prefix": "xx",
"name": "xx",
"type": "2",
...
},
...
]
}好处
很明显，如果接口需要增减参数时，第一种有 list 层级的，前后端处理都会很方便。
比如我加一个字段 other :
{
"state": {
"code": 0,
"msg": "success"
},
"data": {
"list": [ // 这里多一层 list 是有好处的
{
"id": "xx",
"prefix": "xx",
"name": "xx",
"type": "2",
...
},
...
],
"other" : [
...
]
}
}本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号
学习到了 :+1:
看这篇 博客：Api接口实战：ApiResponse接口统一响应封装
正常 data 就是一个数组吧！ 加字段应该和 data 是平级的。
按照 RESTful 接口设计规范，data 要么是一个对象的 list， 要么是单个数据对象。楼主还是举个例子吧，这种扩展性好像是要求 data 返回几种不同类型的数据，感觉有点不符合单一职责原则。
如果API叫
user/list那我觉得data直接是数组没毛病，如果硬要往里面怼其他数据，那接口就不应该叫user/list接口名称和数据的内容应该要有一致性
status、message、data
data下面是需要至少一个键的，这样格式比较统一。
给老哥道个歉， 当时忘了我每次返回的数据是经过 RespondUtil 工具类封装的， 虽然没有刻意的在 data 下包裹 list. 但返回的数据结构类似.....
code 和 message 常用的，建议放外面