接口 api，后端结构返回问题？

[Zach369]

最近跟 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，大家是怎么处理的那？使用那种返回形式？

[kison73]

都可以，主要是沟通好就可以

[tabris17]

当然是有层级的更合理。iOS 只是懒而已

[DevinL]

做为一个后端，当然是支持你了- -

[misaka19000]

显然你的合理，iOS 估计是懒不想处理这么多层级

[justfindu]

当然支持你啊 而且你的接口他们可以直接对 user 和 topic 创建相应的 model. 应该是更方便呀

[zhuzhibin]

例如你的 topic 那一层 只有一个 id 就没必要分层其实 直接外层返回 topic_id

[whypool]

层级太多会被打的

[BrbiwsFtd9zDGZqB]

谁嗓门大听谁的 (支持你的格式

[mhycy]

作为一个前后端都写的表示，iOS 的那个接口建议更不合理 (偷懒+1

[MetalCore]

第一个数据结构 java 常用，第二个数据结构 php 常用

[qiayue]

@MetalCore 不是吧

[SpiderShrimp]

嘻嘻，你的好。虽说都可以实现没错，但是将同个对象的字段抽出来放到一起，可以提高 json 的可读性。

[otakustay]

但是为什么你的 comment_id 不是 comment: {id: xxx}呢？

[Vegetable]

首先，这东西没有什么规则可讲，有的前端比较懒，特点就是
“ XXX 你这几个接口能不能给我合并成一个？”
“这个接口包了这么多层吗？”

你这个数据我看起来，两个设计都有自己的优点，我偏向后边的，不在单个对象中包含二级对象，使用前缀进行区分。第一个那个多层数据结构，不局限在前端，如果想映射成对象，第一个做法是只定义一个对象，有所有的字段，第二个是定义 3 个对象，分别是记录本身，User 对象和 Topic 对象再进行关联，太麻烦了。

[tabris17]

@SpiderShrimp json 是给程序用的，又不是给你读的，真要读转换成 yaml 格式呗

[SpiderShrimp]

@tabris17 是吗？你没对接过吗？后端制定 json，前端难道不用理解？不理解如何编码呢？

[tabris17]

@SpiderShrimp 把 json 转成 yaml 给他读呗，文档是文档，代码是代码

[MarkOrca]

让前端给出理由，然后写进文档，说到底是给前端用的，他要什么样的就什么样的呗。

[SpiderShrimp]

@tabris17 多此一举。后面的那个那么多 topic 前缀，倘若 topic 字段多了，看起来肯定没上面的舒服，但如果像前面 13#说的 comment_id 这种，字段只有一个，那就没必要抽成一个对象。

[xrzxrzxrz]

第一种分层结构比较清晰明了，好理解，比较面相对象，不过嵌套多层
第二种用起来方便，结构就没那么清晰了，也可以说是懒吧 0 0
不过我觉得其实各有利弊吧，毕竟开发方便些也算是一种优势吧。。（最后就看前端后端谁的态度强硬了）（手动狗头）

[elone]

现在用 GraphQL ,结构上就是第一种。我个人是觉得比较清晰。

[ddbullfrog]

JSON:API

[qq73666]

iOS 合理,数组是有序的!!

[dongisking]

跟你遇到一摸一样的问题，我做了第一个，前端说嵌套太多不方便他丢在组件里，于是我又改成第二种。现在的前端真的爽啊，套数据就完事了

[yuejieee]

作为一个 iOS 开发，显然第一种合理，而且第一种的层级数也没有很多

[woscaizi]

支持 ios，他的更简洁明了。
PS 我是后端程序员。

[zhang5388137]

你的接口只有 ios 接吗, 没有 android 或者 web 接吗

[Zach369]

@zhang5388137 是有的，多端：h5 android ios ..... 我问 android 他们说随意。 怎么都行。 h5 我来写。。

[awanganddong]

公司比较规范的绝大多数是第一种结构。json 层次分明。
至于一把梭把所有数据返给前端这种。其实后端更加省力。

[slgz]

@Vegetable #14 “ XXX 你这几个接口能不能给我合并成一个？” 这个情况你们是咋处理的

[maemual]

支持后端，iOS 就是懒而已

[hauibojek]

都没啥问题吧，叫上安卓端的同事一起讨论统一下就行。

[zhang5388137]

@Zach369 个人认为, 多端情况下, 以后端为主, 这次这个可能好改, android 等等随意, 以后指不定还要改什么东西...

[GroupF]

不支持 ios

[superpeaser]

@slgz 我觉得你说的这种也要分情况，进一个页面一下子请求几个接口也不是太好，之前我们查询一个字段都要整成一个接口，这谁能受得了

[Macolor21]

多层嵌套会降低算法复杂度，当然这一点点的性能损失不对。对于一些大量数据的服务就比较敏感了。没有绝对的对错。

[snail404]

瞎猜：接口是 laravel orm json 返回结构 ， 当然是支持了

[simpler]

第二种难道 不是一起偷懒么

[GzhiYi]

支持后端，没必要再做一次字段处理吧？

[rychan]

各有好坏
第一种层次分明，结构很清晰
第二种只是用起来方便而已

[yixiang]

哪个好放在一边，没有必要听 ios 的意见。

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

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

他不用为他的意见负责。但你写了接口是要给多端负责的。

[a15819620038]

理论上层级越少越好。

[LeeSeoung]

组件需要做成啥样就提供啥样的数据，哪分那么多好坏，你提供第一种，组件要求第二种的格式，你后端就算返回第一种，也还是需要前端去手动拼接，这种东西问清楚前因后果就行了。

[sparkle2015]

作为一个前端和 app 开发者，目前为止用过的是第一种，第二种还没见到过。第一种层次分明，意义明确，而且对于后端实现也更简单 (写过点 rails)，看个 GitHub 的 API 设计: https://developer.github.com/v3/repos/comments/#response。第二种无论是客户端还是后端的角度我个人都接受不了。

[Vegetable]

@slgz 看嗓门

[Egfly]

支持第一种，因为我就是这么处理的 ( :dog)。 我们前端也能接受第一种，但是要能处理成第二种他们更乐意

[fhvch]

哥们，我觉得你给的数据没毛病~

[Hyseen]

作为一个后端，当然是支持第一种了

[optional]

当然是第一种，如果前端喜欢第二种让他自己处理

[learnshare]

你做得对，比较合理

[encro]

当然第一种，model 关联，接口数据就出来了，为什么还人工处理一层，浪费时间，容易出 BUG。
问题在于你们写的模型不一样，你可以搜索一个好点的客户端代码 JSON 解析器？

[also24]

如果 user topic 这两个结构，在其它接口中也有出现，且结构逻辑统一，我觉得第一种更好一些。

如果这只是一个单独的接口，我觉得两种都可以接受。
但是第二种对客户端来说，在反序列化的时候会更方便一些。

[IamUNICODE]

几年前我坚持第一个，因为我觉得这样分更合理，后来跟手机端对接久了，就第二个了。。。手机端水平不一样，遇到一个好的不容易，他们要什么就什么吧。。。

[youxiachai]

ios 解析 json 还是不方便....
不过也是 ios 赖....

[Felldeadbird]

我觉得第二个好。第一个层次清晰，但是呢浪费了自己时间啊。因为用你接口的人，有时候喜欢平级一次性输出所有东西，偷懒啊。

当然，具体看业务发展。如果后续需要更复杂的交互，必定第一种。

[zifangsky]

作为一个后端，当然是支持第一种了

[oaix]

嵌套的模型也可以返回展平的结构的。
@JsonUnwrapped 是你的好朋友

[lazypu]

有个问题, 这里的 data 是指什么?

[jjianwen68]

个人倾向第一种，逻辑清晰

[11ssss]

做为一个后端，当然是支持你了

[Airon]

作为一个后端，方便的情况下会返回第二个。因为懒得和用户端开发扯皮。

[varrily]

graphql 是否能解决你们的争议？

[0x000007]

不出现这种我都能接受
```
{
"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]

@0x000007 你的 markdown 没解析出来。没理解你的意思。为什么不能接受第一种那？

[hzb]

前端,个人理解
为什么有时候更想要扁平化的数据结构
因为有的时候结构如果是 a.b.c 某条数据后端返回的 a 是 null 前端直接报错
难道写代码的时候只要超过 2 层的数据结构 都写 a?.b?.c 这种吗

[kkkkkrua]

打一架，谁赢了听谁的
自己在 mvc 写个 body 拦截，解析成 ios 要求的不就好了
对于 java 开发不可见，也不必关心，对 iOS 开发他也舒服

[EastLord]

IOS 想偷懒吧

[yehuzi]

支持楼主接口+1

[banliyaya]

作为一个菜鸡前端，我更倾向于第一种，结构很清晰，有些东西分个类比较好。

[sth2018]

前端，支持你

[yanqing07]

第一种好。
如果这些数据还需要修改后提交后端更新，第一种直接拿来返回给后端就可以了，后端处理起来也不费力
——来自一个前后端一脚踢的留言

[yiqiao]

@MetalCore 我怎么感觉你在黑 PHP。。。

[1762628386]

建议收购公司，夺取话语权，炒他鱿鱼。

[WispZhan]

把这个 iOS 开了换一个

[CantSee]

菜鸡感觉,返回参数分类型的,一个类型在一个 json 里面是最好的,这 ios 就是懒

[MetalCore]

@yiqiao 早期不用 orm 的时候是这样的吧，我不是，我没有，别瞎说（

[daguaochengtang]

@hzb a?.b?.c 是新的语法糖？好像没有这种写法吧。我平时是 a&&a.b&&a.b.c，这种写法确实是恶心的，但是用层级结构数据确实要更清晰一点。各有利弊吧

[daguaochengtang]

@0x000007 哈哈，我们 php 也是经常给我返回这种，明明需要数组。php 里这种`1:{},2: {}`形式的好像也叫数组，也是很奇葩了。

[Zach369]

@nikolausliu 不要黑 php 吧，我也是 php，虽然我也写 golang 和 java。 但是 php 是最好的语言。。。

[liukanshan]

看关系决定改不改 纠结这种问题没有任何意义

[nigelvon]

前端要是组件化肯定第一种更爽，对象配组件，要是返回第二种反而工作量大。

[xFrye]

@0x000007 你的后端想必是个 php。。别问我为啥知道的~~~ 不过后面沟通之后弄回 jsonArray

[coderyoung2017]

关键还是沟通吧

[V2exUser]

@0x000007
哈哈哈哈 又黑 Php

[jieyuanz24]

显然第一种合理

[chinagxwei]

压根只是 ios 懒……，这个层级数并没有很多

[xjq]

graphql 用的人多吗

[MonoLogueChi]

都合理，但是第二种写起来会方便一点

[leopku]

换 graphql，想要或不想要让他自己决定

[turi]

看起来，你合理。
但是你们写之前不都沟通定义一下的吗？

[Vitta]

只要不是动态的 key 我都能接受

[daguaochengtang]

@Zach369 这不算黑吧。。。只是吐槽

[StarkWhite]

@xjq 很多国内外大公司都在用 GraphQL 了，看这个帖子就知道多火了
v2ex.com/t/589138