V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Zach369
V2EX  ›  API

接口 api,后端结构返回问题?

  •  
  •   Zach369 · 2019-08-30 10:00:20 +08:00 · 8125 次点击
    这是一个创建于 1906 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近跟 ios 接口联调,ios 说我的 api 接口返回格式不合理。想问问大家工作中是怎么处理的?

    我的接口返回样子:

       {
         "data": [
           {
             "id": 28,
             "action": 2,
             "user": {
               "id": 1,
               "name": "zach",
               "avatar": ""
             },
             "topic": {
               "id": "279a11cf-4a21-4772-ba07-5e51b499252d",
               "title": "",
               "content": "我是蛋糕 我在躲猫猫"
             },
             "comment_id": 1,
             "created_at": 1565834869
           }
         ],
         "pagination": {
           "current_page": 1,
           "per_page": 10,
           "total": 1
         }
       }
    

    ios 想要的数据结构:

      {
        "data": [
          {
            "id": 28,
            "action": 2,
            "user_id": 1,
            "user_name": "zach",
            "user_avatar": "",
            "topic_id": "279a11cf-4a21-4772-ba07-5e51b499252d",
            "topic_title": "xxx",
            "topic_content": "我是蛋糕",
            "comment_id": 1,
            "created_at": 1565834869
          }
        ],
        "pagination": {
          "current_page": 1,
          "per_page": 10,
          "total": 1
        }
    }
    

    两者之间的变化 就是 将 user 和 topic 对象打散成 key:value 的形式。 想问问广大的后端开发人员以及 ios,大家是怎么处理的那?使用那种返回形式?

    93 条回复    2019-09-04 18:31:13 +08:00
    kison73
        1
    kison73  
       2019-08-30 10:02:53 +08:00
    都可以,主要是沟通好就可以
    tabris17
        2
    tabris17  
       2019-08-30 10:03:18 +08:00   ❤️ 14
    当然是有层级的更合理。iOS 只是懒而已
    DevinL
        3
    DevinL  
       2019-08-30 10:03:21 +08:00
    做为一个后端,当然是支持你了- -
    misaka19000
        4
    misaka19000  
       2019-08-30 10:03:50 +08:00   ❤️ 1
    显然你的合理,iOS 估计是懒不想处理这么多层级
    justfindu
        5
    justfindu  
       2019-08-30 10:05:19 +08:00
    当然支持你啊 而且你的接口他们可以直接对 user 和 topic 创建相应的 model. 应该是更方便呀
    zhuzhibin
        6
    zhuzhibin  
       2019-08-30 10:05:47 +08:00 via iPhone
    例如你的 topic 那一层 只有一个 id 就没必要分层其实 直接外层返回 topic_id
    whypool
        7
    whypool  
       2019-08-30 10:06:42 +08:00
    层级太多会被打的
    90d0n
        8
    90d0n  
       2019-08-30 10:07:38 +08:00
    谁嗓门大听谁的 (支持你的格式
    mhycy
        9
    mhycy  
       2019-08-30 10:07:46 +08:00   ❤️ 1
    作为一个前后端都写的表示,iOS 的那个接口建议更不合理 (偷懒+1
    MetalCore
        10
    MetalCore  
       2019-08-30 10:08:31 +08:00
    第一个数据结构 java 常用,第二个数据结构 php 常用
    qiayue
        11
    qiayue  
       2019-08-30 10:09:57 +08:00
    @MetalCore 不是吧
    SpiderShrimp
        12
    SpiderShrimp  
       2019-08-30 10:10:59 +08:00
    嘻嘻,你的好。虽说都可以实现没错,但是将同个对象的字段抽出来放到一起,可以提高 json 的可读性。
    otakustay
        13
    otakustay  
       2019-08-30 10:11:27 +08:00
    但是为什么你的 comment_id 不是 comment: {id: xxx}呢?
    Vegetable
        14
    Vegetable  
       2019-08-30 10:12:27 +08:00
    首先,这东西没有什么规则可讲,有的前端比较懒,特点就是
    “ XXX 你这几个接口能不能给我合并成一个?”
    “这个接口包了这么多层吗?”

    你这个数据我看起来,两个设计都有自己的优点,我偏向后边的,不在单个对象中包含二级对象,使用前缀进行区分。第一个那个多层数据结构,不局限在前端,如果想映射成对象,第一个做法是只定义一个对象,有所有的字段,第二个是定义 3 个对象,分别是记录本身,User 对象和 Topic 对象再进行关联,太麻烦了。
    tabris17
        15
    tabris17  
       2019-08-30 10:12:43 +08:00
    @SpiderShrimp json 是给程序用的,又不是给你读的,真要读转换成 yaml 格式呗
    SpiderShrimp
        16
    SpiderShrimp  
       2019-08-30 10:14:50 +08:00
    @tabris17 是吗?你没对接过吗?后端制定 json,前端难道不用理解?不理解如何编码呢?
    tabris17
        17
    tabris17  
       2019-08-30 10:17:30 +08:00
    @SpiderShrimp 把 json 转成 yaml 给他读呗,文档是文档,代码是代码
    MarkOrca
        18
    MarkOrca  
       2019-08-30 10:18:06 +08:00
    让前端给出理由,然后写进文档,说到底是给前端用的,他要什么样的就什么样的呗。
    SpiderShrimp
        19
    SpiderShrimp  
       2019-08-30 10:21:26 +08:00
    @tabris17 多此一举。后面的那个那么多 topic 前缀,倘若 topic 字段多了,看起来肯定没上面的舒服,但如果像前面 13#说的 comment_id 这种,字段只有一个,那就没必要抽成一个对象。
    xrzxrzxrz
        20
    xrzxrzxrz  
       2019-08-30 10:23:46 +08:00
    第一种分层结构比较清晰明了,好理解,比较面相对象,不过嵌套多层
    第二种用起来方便,结构就没那么清晰了,也可以说是懒吧 0 0
    不过我觉得其实各有利弊吧,毕竟开发方便些也算是一种优势吧。。(最后就看前端后端谁的态度强硬了)(手动狗头)
    elone
        21
    elone  
       2019-08-30 10:35:50 +08:00   ❤️ 1
    现在用 GraphQL ,结构上就是第一种。我个人是觉得比较清晰。
    ddbullfrog
        22
    ddbullfrog  
       2019-08-30 10:37:56 +08:00
    JSON:API
    qq73666
        23
    qq73666  
       2019-08-30 10:38:28 +08:00
    iOS 合理,数组是有序的!!
    dongisking
        24
    dongisking  
       2019-08-30 10:40:46 +08:00 via Android
    跟你遇到一摸一样的问题,我做了第一个,前端说嵌套太多不方便他丢在组件里,于是我又改成第二种。现在的前端真的爽啊,套数据就完事了
    yuejieee
        25
    yuejieee  
       2019-08-30 10:41:39 +08:00
    作为一个 iOS 开发,显然第一种合理,而且第一种的层级数也没有很多
    woscaizi
        26
    woscaizi  
       2019-08-30 10:45:33 +08:00 via iPhone
    支持 ios,他的更简洁明了。
    PS 我是后端程序员。
    zhang5388137
        27
    zhang5388137  
       2019-08-30 10:48:10 +08:00
    你的接口只有 ios 接吗, 没有 android 或者 web 接吗
    Zach369
        28
    Zach369  
    OP
       2019-08-30 10:58:09 +08:00
    @zhang5388137 是有的,多端:h5 android ios ..... 我问 android 他们说随意。 怎么都行。 h5 我来写。。
    awanganddong
        29
    awanganddong  
       2019-08-30 11:09:53 +08:00
    公司比较规范的绝大多数是第一种结构。json 层次分明。
    至于一把梭把所有数据返给前端这种。其实后端更加省力。
    slgz
        30
    slgz  
       2019-08-30 11:23:34 +08:00
    @Vegetable #14 “ XXX 你这几个接口能不能给我合并成一个?” 这个情况你们是咋处理的
    maemual
        31
    maemual  
       2019-08-30 11:25:27 +08:00
    支持后端,iOS 就是懒而已
    hauibojek
        32
    hauibojek  
       2019-08-30 11:26:07 +08:00
    都没啥问题吧,叫上安卓端的同事一起讨论统一下就行。
    zhang5388137
        33
    zhang5388137  
       2019-08-30 11:26:56 +08:00
    @Zach369 个人认为, 多端情况下, 以后端为主, 这次这个可能好改, android 等等随意, 以后指不定还要改什么东西...
    GroupF
        34
    GroupF  
       2019-08-30 11:27:34 +08:00
    不支持 ios
    superpeaser
        35
    superpeaser  
       2019-08-30 11:40:41 +08:00
    @slgz 我觉得你说的这种也要分情况,进一个页面一下子请求几个接口也不是太好,之前我们查询一个字段都要整成一个接口,这谁能受得了
    Macolor21
        36
    Macolor21  
       2019-08-30 11:50:35 +08:00 via iPhone
    多层嵌套会降低算法复杂度,当然这一点点的性能损失不对。对于一些大量数据的服务就比较敏感了。没有绝对的对错。
    snail404
        37
    snail404  
       2019-08-30 11:58:09 +08:00
    瞎猜:接口是 laravel orm json 返回结构 , 当然是支持了
    simpler
        38
    simpler  
       2019-08-30 12:00:59 +08:00
    第二种难道 不是一起偷懒么
    GzhiYi
        39
    GzhiYi  
       2019-08-30 12:06:16 +08:00 via iPhone   ❤️ 1
    支持后端,没必要再做一次字段处理吧?
    rychan
        40
    rychan  
       2019-08-30 12:08:14 +08:00
    各有好坏
    第一种层次分明,结构很清晰
    第二种只是用起来方便而已
    yixiang
        41
    yixiang  
       2019-08-30 12:21:04 +08:00
    哪个好放在一边,没有必要听 ios 的意见。

    既然后端接口是给多个端用的,那就不应该照顾单独一个端的开发,而是后端人员说了算。

    假设安卓先开发完成,已上线,ios 说接口格式不合理,于是你改了格式,然后安卓端崩了,谁的锅?首先是团队总负责人(流程分工不清晰),其次是实际负责后端的后端人员,再次才是提出意见的 ios。

    他不用为他的意见负责。但你写了接口是要给多端负责的。
    a15819620038
        42
    a15819620038  
       2019-08-30 12:46:09 +08:00
    理论上层级越少越好。
    LeeSeoung
        43
    LeeSeoung  
       2019-08-30 12:46:17 +08:00
    组件需要做成啥样就提供啥样的数据,哪分那么多好坏,你提供第一种,组件要求第二种的格式,你后端就算返回第一种,也还是需要前端去手动拼接,这种东西问清楚前因后果就行了。
    sparkle2015
        44
    sparkle2015  
       2019-08-30 13:28:53 +08:00
    作为一个前端和 app 开发者,目前为止用过的是第一种,第二种还没见到过。第一种层次分明,意义明确,而且对于后端实现也更简单 (写过点 rails),看个 GitHub 的 API 设计: https://developer.github.com/v3/repos/comments/#response。第二种无论是客户端还是后端的角度我个人都接受不了。
    Vegetable
        45
    Vegetable  
       2019-08-30 13:32:49 +08:00
    @slgz 看嗓门
    Egfly
        46
    Egfly  
       2019-08-30 13:40:19 +08:00
    支持第一种,因为我就是这么处理的 ( :dog)。 我们前端也能接受第一种,但是要能处理成第二种他们更乐意
    fhvch
        47
    fhvch  
       2019-08-30 13:49:20 +08:00
    哥们,我觉得你给的数据没毛病~
    Hyseen
        48
    Hyseen  
       2019-08-30 13:55:56 +08:00
    作为一个后端,当然是支持第一种了
    optional
        49
    optional  
       2019-08-30 14:03:38 +08:00
    当然是第一种,如果前端喜欢第二种让他自己处理
    learnshare
        50
    learnshare  
       2019-08-30 14:08:33 +08:00
    你做得对,比较合理
    encro
        51
    encro  
       2019-08-30 14:14:30 +08:00
    当然第一种,model 关联,接口数据就出来了,为什么还人工处理一层,浪费时间,容易出 BUG。
    问题在于你们写的模型不一样,你可以搜索一个好点的客户端代码 JSON 解析器?
    also24
        52
    also24  
       2019-08-30 14:24:25 +08:00
    如果 user topic 这两个结构,在其它接口中也有出现,且结构逻辑统一,我觉得第一种更好一些。

    如果这只是一个单独的接口,我觉得两种都可以接受。
    但是第二种对客户端来说,在反序列化的时候会更方便一些。
    IamUNICODE
        53
    IamUNICODE  
       2019-08-30 14:30:10 +08:00   ❤️ 1
    几年前我坚持第一个,因为我觉得这样分更合理,后来跟手机端对接久了,就第二个了。。。手机端水平不一样,遇到一个好的不容易,他们要什么就什么吧。。。
    youxiachai
        54
    youxiachai  
       2019-08-30 14:37:29 +08:00
    ios 解析 json 还是不方便....
    不过也是 ios 赖....
    Felldeadbird
        55
    Felldeadbird  
       2019-08-30 14:48:49 +08:00
    我觉得第二个好。第一个层次清晰,但是呢浪费了自己时间啊。因为用你接口的人,有时候喜欢平级一次性输出所有东西,偷懒啊。

    当然,具体看业务发展。如果后续需要更复杂的交互,必定第一种。
    zifangsky
        56
    zifangsky  
       2019-08-30 14:56:50 +08:00
    作为一个后端,当然是支持第一种了
    oaix
        57
    oaix  
       2019-08-30 15:33:01 +08:00
    嵌套的模型也可以返回展平的结构的。
    @JsonUnwrapped 是你的好朋友
    linxl
        58
    linxl  
       2019-08-30 15:38:58 +08:00
    有个问题, 这里的 data 是指什么?
    jjianwen68
        59
    jjianwen68  
       2019-08-30 15:48:08 +08:00
    个人倾向第一种,逻辑清晰
    11ssss
        60
    11ssss  
       2019-08-30 15:49:10 +08:00
    做为一个后端,当然是支持你了
    Airon
        61
    Airon  
       2019-08-30 15:49:19 +08:00
    作为一个后端,方便的情况下会返回第二个。因为懒得和用户端开发扯皮。
    varrily
        62
    varrily  
       2019-08-30 15:59:39 +08:00
    graphql 是否能解决你们的争议?
    0x000007
        63
    0x000007  
       2019-08-30 16:15:38 +08:00
    不出现这种我都能接受
    ```
    {
    "data": {
    1: {
    "id": 28,
    "action": 2,
    "user": {
    "id": 1,
    "name": "zach",
    "avatar": ""
    },
    "topic": {
    "id": "279a11cf-4a21-4772-ba07-5e51b499252d",
    "title": "",
    "content": "我是蛋糕 我在躲猫猫"
    },
    "comment_id": 1,
    "created_at": 1565834869
    }
    },
    "pagination": {
    "current_page": 1,
    "per_page": 10,
    "total": 1
    }
    }
    ```
    Zach369
        64
    Zach369  
    OP
       2019-08-30 16:27:12 +08:00
    @0x000007 你的 markdown 没解析出来。没理解你的意思。为什么不能接受第一种那?
    hzb
        65
    hzb  
       2019-08-30 16:38:17 +08:00
    前端,个人理解
    为什么有时候更想要扁平化的数据结构
    因为有的时候结构如果是 a.b.c 某条数据后端返回的 a 是 null 前端直接报错
    难道写代码的时候只要超过 2 层的数据结构 都写 a?.b?.c 这种吗
    kkkkkrua
        66
    kkkkkrua  
       2019-08-30 16:40:56 +08:00
    打一架,谁赢了听谁的
    自己在 mvc 写个 body 拦截,解析成 ios 要求的不就好了
    对于 java 开发不可见,也不必关心,对 iOS 开发他也舒服
    EastLord
        67
    EastLord  
       2019-08-30 16:41:10 +08:00
    IOS 想偷懒吧
    yehuzi
        68
    yehuzi  
       2019-08-30 16:57:15 +08:00
    支持楼主接口+1
    banliyaya
        69
    banliyaya  
       2019-08-30 16:59:12 +08:00
    作为一个菜鸡前端,我更倾向于第一种,结构很清晰,有些东西分个类比较好。
    sth2018
        70
    sth2018  
       2019-08-30 17:03:21 +08:00
    前端,支持你
    yanqing07
        71
    yanqing07  
       2019-08-30 17:24:37 +08:00
    第一种好。
    如果这些数据还需要修改后提交后端更新,第一种直接拿来返回给后端就可以了,后端处理起来也不费力
    ——来自一个前后端一脚踢的留言
    yiqiao
        72
    yiqiao  
       2019-08-30 17:25:22 +08:00
    @MetalCore 我怎么感觉你在黑 PHP。。。
    1762628386
        73
    1762628386  
       2019-08-30 17:30:20 +08:00
    建议收购公司,夺取话语权,炒他鱿鱼。
    WispZhan
        74
    WispZhan  
       2019-08-30 17:37:24 +08:00 via Android
    把这个 iOS 开了换一个
    CantSee
        75
    CantSee  
       2019-08-30 17:41:38 +08:00
    菜鸡感觉,返回参数分类型的,一个类型在一个 json 里面是最好的,这 ios 就是懒
    MetalCore
        76
    MetalCore  
       2019-08-30 17:42:08 +08:00
    @yiqiao 早期不用 orm 的时候是这样的吧,我不是,我没有,别瞎说(
    daguaochengtang
        77
    daguaochengtang  
       2019-08-30 18:02:54 +08:00
    @hzb a?.b?.c 是新的语法糖?好像没有这种写法吧。我平时是 a&&a.b&&a.b.c,这种写法确实是恶心的,但是用层级结构数据确实要更清晰一点。各有利弊吧
    daguaochengtang
        78
    daguaochengtang  
       2019-08-30 18:05:36 +08:00
    @0x000007 哈哈,我们 php 也是经常给我返回这种,明明需要数组。php 里这种`1:{},2: {}`形式的好像也叫数组,也是很奇葩了。
    Zach369
        79
    Zach369  
    OP
       2019-08-30 18:27:01 +08:00
    @nikolausliu 不要黑 php 吧,我也是 php,虽然我也写 golang 和 java。 但是 php 是最好的语言。。。
    liukanshan
        80
    liukanshan  
       2019-08-30 18:35:56 +08:00
    看关系决定改不改 纠结这种问题没有任何意义
    nigelvon
        81
    nigelvon  
       2019-08-30 18:36:37 +08:00
    前端要是组件化肯定第一种更爽,对象配组件,要是返回第二种反而工作量大。
    xFrye
        82
    xFrye  
       2019-08-30 19:10:29 +08:00
    @0x000007 你的后端想必是个 php。。别问我为啥知道的~~~ 不过后面沟通之后弄回 jsonArray
    coderyoung2017
        83
    coderyoung2017  
       2019-08-30 19:16:29 +08:00
    关键还是沟通吧
    V2exUser
        84
    V2exUser  
       2019-08-30 22:36:55 +08:00
    @0x000007
    哈哈哈哈 又黑 Php
    jieyuanz24
        85
    jieyuanz24  
       2019-08-30 23:10:54 +08:00
    显然第一种合理
    chinagxwei
        86
    chinagxwei  
       2019-08-30 23:59:14 +08:00
    压根只是 ios 懒……,这个层级数并没有很多
    xjq
        87
    xjq  
       2019-08-31 00:01:43 +08:00 via Android
    graphql 用的人多吗
    MonoLogueChi
        88
    MonoLogueChi  
       2019-08-31 00:03:50 +08:00 via Android
    都合理,但是第二种写起来会方便一点
    leopku
        89
    leopku  
       2019-08-31 08:22:42 +08:00   ❤️ 1
    换 graphql,想要或不想要让他自己决定
    turi
        90
    turi  
       2019-08-31 10:07:08 +08:00
    看起来,你合理。
    但是你们写之前不都沟通定义一下的吗?
    Vitta
        91
    Vitta  
       2019-08-31 10:09:44 +08:00
    只要不是动态的 key 我都能接受
    daguaochengtang
        92
    daguaochengtang  
       2019-09-02 17:22:32 +08:00
    @Zach369 这不算黑吧。。。只是吐槽
    StarkWhite
        93
    StarkWhite  
       2019-09-04 18:31:13 +08:00
    @xjq 很多国内外大公司都在用 GraphQL 了,看这个帖子就知道多火了
    v2ex.com/t/589138
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   918 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 20:42 · PVG 04:42 · LAX 12:42 · JFK 15:42
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.