Zach369
V2EX  ›  API

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

  •  
  •   Zach369 · Aug 30, 2019 · 9981 views
    This topic created in 2623 days ago, the information mentioned may be changed or developed.

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

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

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

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

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

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

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