这是一个创建于 2235 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近跟 ios 接口联调，ios 说我的 api 接口返回格式不合理。想问问大家工作中是怎么处理的？
我的接口返回样子：
{ "data": [ { "id": 28, "action": 2, "user": { "id": 1, "name": "zach", "avatar": "" }, "topic": { "id": "279a11cf-4a21-4772-a07-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 2019-08-30 10:02:53 +08:00 都可以，主要是沟通好就可以 |
 | 2 tabris17 2019-08-30 10:03:18 +08:00  14 当然是有层级的更合理。iOS 只是懒而已 |
 | 3 DevinL 2019-08-30 10:03:21 +08:00 做为一个后端，当然是支持你了- - |
 | 4 misaka19000 2019-08-30 10:03:50 +08:00 1 显然你的合理，iOS 估计是懒不想处理这么多层级 |
 | 5 justfindu 2019-08-30 10:05:19 +08:00 当然支持你啊 而且你的接口他们可以直接对 user 和 topic 创建相应的 model. 应该是更方便呀 |
 | 6 zhuzhibin 2019-08-30 10:05:47 +08:00 via iPhone 例如你的 topic 那一层 只有一个 id 就没必要分层其实 直接外层返回 topic_id |
7 whypool 2019-08-30 10:06:42 +08:00 层级太多会被打的 |
 | 8 BrbiwsFtd9zDGZqB 2019-08-30 10:07:38 +08:00 谁嗓门大听谁的 (支持你的格式 |
 | 9 mhycy 2019-08-30 10:07:46 +08:00 1 作为一个前后端都写的表示，iOS 的那个接口建议更不合理 (偷懒+1 |
 | 10 MetalCore 2019-08-30 10:08:31 +08:00 第一个数据结构 java 常用，第二个数据结构 php 常用 |
 | 12 SpiderShrimp 2019-08-30 10:10:59 +08:00 嘻嘻，你的好。虽说都可以实现没错，但是将同个对象的字段抽出来放到一起，可以提高 json 的可读性。 |
 | 13 otakustay 2019-08-30 10:11:27 +08:00 但是为什么你的 comment_id 不是 comment: {id: xxx}呢？ |
 | 14 Vegetable 2019-08-30 10:12:27 +08:00 div class="reply_content">首先，这东西没有什么规则可讲，有的前端比较懒，特点就是“ XXX 你这几个接口能不能给我合并成一个？” “这个接口包了这么多层吗？” 你这个数据我看起来，两个设计都有自己的优点，我偏向后边的，不在单个对象中包含二级对象，使用前缀进行区分。第一个那个多层数据结构，不局限在前端，如果想映射成对象，第一个做法是只定义一个对象，有所有的字段，第二个是定义 3 个对象，分别是记录本身，User 对象和 Topic 对象再进行关联，太麻烦了。 |
| 15 tabris17 2019-08-30 10:12:43 +08:00 @SpiderShrimp json 是给程序用的，又不是给你读的，真要读转换成 yaml 格式呗 |
| 16 SpiderShrimp 2019-08-30 10:14:50 +08:00 @tabris17 是吗？你没对接过吗？后端制定 json，前端难道不用理解？不理解如何编码呢？ |
| 17 tabris17 2019-08-30 10:17:30 +08:00 @SpiderShrimp 把 json 转成 yaml 给他读呗，文档是文档，代码是代码 |
 | 18 MarkOrca 2019-08-30 10:18:06 +08:00 让前端给出理由，然后写进文档，说到底是给前端用的，他要什么样的就什么样的呗。 |
| 19 SpiderShrimp 2019-08-30 10:21:26 +08:00 @tabris17 多此一举。后面的那个那么多 topic 前缀，倘若 topic 字段多了，看起来肯定没上面的舒服，但如果像前面 13#说的 comment_id 这种，字段只有一个，那就没必要抽成一个对象。 |
 | 20 xrzxrzxrz 2019-08-30 10:23:46 +08:00 第一种分层结构比较清晰明了，好理解，比较面相对象，不过嵌套多层 第二种用起来方便，结构就没那么清晰了，也可以说是懒吧 0 0 不过我觉得其实各有利弊吧，毕竟开发方便些也算是一种优势吧。。（最后就看前端后端谁的态度强硬了）（手动狗头） |
 | 21 elone 2019-08-30 10:35:50 +08:00 1 现在用 GraphQL ,结构上就是第一种。我个人是觉得比较清晰。 |
 | 22 ddbullfrog 2019-08-30 10:37:56 +08:00 JSON:API |
 | 23 qq73666 2019-08-30 10:38:28 +08:00 iOS 合理,数组是有序的!! |
 | 24 dongisking 2019-08-30 10:40:46 +08:00 via Android 跟你遇到一摸一样的问题，我做了第一个，前端说嵌套太多不方便他丢在组件里，于是我又改成第二种。现在的前端真的爽啊，套数据就完事了 |
 | 25 yuejieee 2019-08-30 10:41:39 +08:00 作为一个 iOS 开发，显然第一种合理，而且第一种的层级数也没有很多 |
 | 26 woscaizi 2019-08-30 10:45:33 +08:00 via iPhone 支持 ios，他的更简洁明了。 PS 我是后端程序员。 |
 | 27 zhang5388137 2019-08-30 10:48:10 +08:00 你的接口只有 ios 接吗, 没有 android 或者 web 接吗 |
 | 28 Zach369 OP @zhang5388137 是有的，多端：h5 android ios ..... 我问 android 他们说随意。 怎么都行。 h5 我来写。。 |
 | 29 awanganddong 2019-08-30 11:09:53 +08:00 公司比较规范的绝大多数是第一种结构。json 层次分明。 至于一把梭把所有数据返给前端这种。其实后端更加省力。 |
 | 31 maemual 2019-08-30 11:25:27 +08:00 支持后端，iOS 就是懒而已 |
 | 32 hauibojek 2019-08-30 11:26:07 +08:00 都没啥问题吧，叫上安卓端的同事一起讨论统一下就行。 |
| 33 zhang5388137 2019-08-30 11:26:56 +08:00 @Zach369 个人认为, 多端情况下, 以后端为主, 这次这个可能好改, android 等等随意, 以后指不定还要改什么东西... |
 | 34 GroupF 2019-08-30 11:27:34 +08:00 不支持 ios |
 | 35 superpeaser 2019-08-30 11:40:41 +08:00 @slgz 我觉得你说的这种也要分情况，进一个页面一下子请求几个接口也不是太好，之前我们查询一个字段都要整成一个接口，这谁能受得了 |
 | 36 Macolor21 2019-08-30 11:50:35 +08:00 via iPhone 多层嵌套会降低算法复杂度，当然这一点点的性能损失不对。对于一些大量数据的服务就比较敏感了。没有绝对的对错。 |
 | 37 snail404 2019-08-30 11:58:09 +08:00 瞎猜：接口是 laravel orm json 返回结构 ， 当然是支持了 |
 | 38 simpler 2019-08-30 12:00:59 +08:00 第二种难道 不是一起偷懒么 |
 | 39 GzhiYi 2019-08-30 12:06:16 +08:00 via iPhone 1 支持后端，没必要再做一次字段处理吧？ |
 | 40 rychan 2019-08-30 12:08:14 +08:00 各有好坏 第一种层次分明，结构很清晰 第二种只是用起来方便而已 |
 | 41 yixiang 2019-08-30 12:21:04 +08:00 哪个好放在一边，没有必要听 ios 的意见。 既然后端接口是给多个端用的，那就不应该照顾单独一个端的开发，而是后端人员说了算。 假设安卓先开发完成，已上线，ios 说接口格式不合理，于是你改了格式，然后安卓端崩了，谁的锅？首先是团队总负责人（流程分工不清晰），其次是实际负责后端的后端人员，再次才是提出意见的 ios。 他不用为他的意见负责。但你写了接口是要给多端负责的。 |
 | 42 a15819620038 2019-08-30 12:46:09 +08:00 理论上层级越少越好。 |
 | 43 LeeSeoung 2019-08-30 12:46:17 +08:00 组件需要做成啥样就提供啥样的数据，哪分那么多好坏，你提供第一种，组件要求第二种的格式，你后端就算返回第一种，也还是需要前端去手动拼接，这种东西问清楚前因后果就行了。 |
 | 44 sparkle2015 2019-08-30 13:28:53 +08:00 作为一个前端和 app 开发者，目前为止用过的是第一种，第二种还没见到过。第一种层次分明，意义明确，而且对于后端实现也更简单 (写过点 rails)，看个 GitHub 的 API 设计: https://developer.github.com/v3/repos/comments/#response。第二种无论是客户端还是后端的角度我个人都接受不了。 |
 | 46 Egfly 2019-08-30 13:40:19 +08:00 支持第一种，因为我就是这么处理的 ( :dog)。 我们前端也能接受第一种，但是要能处理成第二种他们更乐意 |
 | 47 fhvch 2019-08-30 13:49:20 +08:00 哥们，我觉得你给的数据没毛病~ |
 | 48 Hyseen 2019-08-30 13:55:56 +08:00 作为一个后端，当然是支持第一种了 |
 | 49 optional 2019-08-30 14:03:38 +08:00 当然是第一种，如果前端喜欢第二种让他自己处理 |
 | 50 learnshare 2019-08-30 14:08:33 +08:00 你做得对，比较合理 |
 | 51 encro 2019-08-30 14:14:30 +08:00 当然第一种，model 关联，接口数据就出来了，为什么还人工处理一层，浪费时间，容易出 BUG。 问题在于你们写的模型不一样，你可以搜索一个好点的客户端代码 JSON 解析器？ |
 | 52 also24 2019-08-30 14:24:25 +08:00 如果 user topic 这两个结构，在其它接口中也有出现，且结构逻辑统一，我觉得第一种更好一些。 如果这只是一个单独的接口，我觉得两种都可以接受。 但是第二种对客户端来说，在反序列化的时候会更方便一些。 |
 | 53 IamUNICODE 2019-08-30 14:30:10 +08:00 1 几年前我坚持第一个，因为我觉得这样分更合理，后来跟手机端对接久了，就第二个了。。。手机端水平不一样，遇到一个好的不容易，他们要什么就什么吧。。。 |
 | 54 youxiachai 2019-08-30 14:37:29 +08:00 ios 解析 json 还是不方便.... 不过也是 ios 赖.... |
 | 55 Felldeadbird 2019-08-30 14:48:49 +08:00 我觉得第二个好。第一个层次清晰，但是呢浪费了自己时间啊。因为用你接口的人，有时候喜欢平级一次性输出所有东西，偷懒啊。 当然，具体看业务发展。如果后续需要更复杂的交互，必定第一种。 |
 | 56 zifangsky 2019-08-30 14:56:50 +08:00 作为一个后端，当然是支持第一种了 |
 | 57 oaix 2019-08-30 15:33:01 +08:00 嵌套的模型也可以返回展平的结构的。 @JsonUnwrapped 是你的好朋友 |
 | 58 linxl 2019-08-30 15:38:58 +08:00 有个问题, 这里的 data 是指什么? |
 | 59 jjianwen68 2019-08-30 15:48:08 +08:00 个人倾向第一种，逻辑清晰 |
 | 60 11ssss 2019-08-30 15:49:10 +08:00 做为一个后端，当然是支持你了 |
 | 61 Airon 2019-08-30 15:49:19 +08:00 作为一个后端，方便的情况下会返回第二个。因为懒得和用户端开发扯皮。 |
 | 62 varrily 2019-08-30 15:59:39 +08:00 graphql 是否能解决你们的争议？ |
 | 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 } } ``` |
 | 65 hzb 2019-08-30 16:38:17 +08:00 前端,个人理解 为什么有时候更想要扁平化的数据结构 因为有的时候结构如果是 a.b.c 某条数据后端返回的 a 是 null 前端直接报错 难道写代码的时候只要超过 2 层的数据结构 都写 a?.b?.c 这种吗 |
 | 66 kkkkkrua 2019-08-30 16:40:56 +08:00 打一架，谁赢了听谁的 自己在 mvc 写个 body 拦截，解析成 ios 要求的不就好了 对于 java 开发不可见，也不必关心，对 iOS 开发他也舒服 |
 | 67 EastLord 2019-08-30 16:41:10 +08:00 IOS 想偷懒吧 |
 | 68 yehuzi 2019-08-30 16:57:15 +08:00 支持楼主接口+1 |
 | 69 banliyaya 2019-08-30 16:59:12 +08:00 作为一个菜鸡前端，我更倾向于第一种，结构很清晰，有些东西分个类比较好。 |
 | 70 sth2018 2019-08-30 17:03:21 +08:00 前端，支持你 |
 | 71 yanqing07 2019-08-30 17:24:37 +08:00 第一种好。 如果这些数据还需要修改后提交后端更新，第一种直接拿来返回给后端就可以了，后端处理起来也不费力 来自一个前后端一脚踢的留言 |
 | 73 1762628386 2019-08-30 17:30:20 +08:00 建议收购公司，夺取话语权，炒他鱿鱼。 |
 | 74 WispZhan 2019-08-30 17:37:24 +08:00 via Android 把这个 iOS 开了换一个 |
 | 75 CantSee 2019-08-30 17:41:38 +08:00 菜鸡感觉,返回参数分类型的,一个类型在一个 json 里面是最好的,这 ios 就是懒 |
 | 77 daguaochengtang 2019-08-30 18:02:54 +08:00 @hzb a?.b?.c 是新的语法糖？好像没有这种写法吧。我平时是 a&&a.b&&a.b.c，这种写法确实是恶心的，但是用层级结构数据确实要更清晰一点。各有利弊吧 |
| 78 daguaochengtang 2019-08-30 18:05:36 +08:00 @0x000007 哈哈，我们 php 也是经常给我返回这种，明明需要数组。php 里这种`1:{},2: {}`形式的好像也叫数组，也是很奇葩了。 |
| 79 Zach369 OP @nikolausliu 不要黑 php 吧，我也是 php，虽然我也写 golang 和 java。 但是 php 是最好的语言。。。 |
 | 80 liukanshan 2019-08-30 18:35:56 +08:00 看关系决定改不改 纠结这种问题没有任何意义 |
 | 81 nigelvon 2019-08-30 18:36:37 +08:00 前端要是组件化肯定第一种更爽，对象配组件，要是返回第二种反而工作量大。 |
 | 83 coderyoung2017 2019-08-30 19:16:29 +08:00 关键还是沟通吧 |
 | 85 jieyuanz24 2019-08-30 23:10:54 +08:00 显然第一种合理 |
 | 86 chinagxwei 2019-08-30 23:59:14 +08:00 压根只是 ios 懒……，这个层级数并没有很多 |
 | 87 xjq 2019-08-31 00:01:43 +08:00 via Android graphql 用的人多吗 |
 | 88 MonoLogueChi 2019-08-31 00:03:50 +08:00 via Android 都合理，但是第二种写起来会方便一点 |
 | 89 leopku 2019-08-31 08:22:42 +08:00 1 换 graphql，想要或不想要让他自己决定 |
 | 看起来，你合理。 但是你们写之前不都沟通定义一下的吗？ |
 | 91 Vitta 2019-08-31 10:09:44 +08:00 只要不是动态的 key 我都能接受 |
| 92 daguaochengtang 2019-09-02 17:22:32 +08:00 @Zach369 这不算黑吧。。。只是吐槽 |
 | 93 StarkWhite 2019-09-04 18:31:13 +08:00 |
Select Language