一种建议的接口返回结构

比如建议如下

{
    "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 协议》,转载必须注明作者和本文链接
六月的风
Junwind
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 8

学习到了 :+1:

1年前 评论

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

file

1年前 评论

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

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

1年前 评论

status、message、data

1年前 评论

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

1年前 评论

给老哥道个歉, 当时忘了我每次返回的数据是经过 RespondUtil 工具类封装的, 虽然没有刻意的在 data 下包裹 list. 但返回的数据结构类似.....

file

file

file

1年前 评论

code 和 message 常用的,建议放外面

1年前 评论

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