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