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

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

  •  
  •   Zach369 · 107 天前 · 4645 次点击
    这是一个创建于 107 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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