一种建议的接口返回结构

比如建议如下

{
    "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 协议》,转载必须注明作者和本文链接
六月的风
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 6

学习到了 :+1:

3周前 评论

正常 data 就是一个数组吧! 加字段应该和 data 是平级的。
按照 RESTful 接口设计规范,data 要么是一个对象的 list, 要么是单个数据对象。楼主还是举个例子吧,这种扩展性好像是要求 data 返回几种不同类型的数据,感觉有点不符合单一职责原则。

file

3周前 评论

如果API叫 user/list 那我觉得data 直接是数组没毛病,如果硬要往里面怼其他数据,那接口就不应该叫user/list

接口名称和数据的内容应该要有一致性

3周前 评论

status、message、data

3周前 评论

data下面是需要至少一个键的,这样格式比较统一。

3周前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!