这是一个创建于 1865 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚才有个朋友问我，发生什么事了，
我说怎么回事，给我发了几张截图，我一看，
嗷，原来是刚才，有一个高级后端，将业务数据做为 key 返回给我……
（ 咳咳，举个例子：他返回的是直接一个 jsonObject：{"用户名 1"：1，"用户名 2"：2}，我当时还以为是类似于这种：[{"userName":"用户名 1"，"value":1},{"userName":"用户名 2"，"value":2}] ）
我说可以，我说是不是应该按格式来，这样不好用，
他不服气，我说大佬，你用这种方式返回数据，那怎么转成实体类呢？
我一说他啪就站起来了，很快啊，然后上来就是一句自己解析 json 数据不就行了，
我全部防出去了啊，防出去以后，自然是以商量的语气问下能不能以固定格式的方式，至少能转成实体类，这样大家都舒服，毕竟接口嘛，最好固定格式，这样无论从维护角度还是可用性来说都很不错的
结果他说我是有备而来的，这个只有四年工作经验，还是外包的年轻人不讲武德，来，骗，来，偷袭，他这个高级后端的老同志，这好吗？这不好，他劝我这位年轻人好自为之，好好反思，以后不要再犯这样的错误，小聪明啊，工作要以和为贵，要讲武德，不要搞窝里斗
咳咳，最后当然是以大佬说的为准，毕竟按他的说法
为什么你一定执着于这个非固定 key 这个 jsonobj 和 class 有什么不一样么？
以上纯属根据自身经历而来的逗乐吐槽……如有雷同冒犯，请轻喷~~~~
第 1 条附言 2020-11-15 13:02:58 +08:00
省流精简版：
后端把业务数据当作 key 值返回给展示端……
后端把业务数据当作 key 值返回给展示端……
第 2 条附言 2020-11-15 14:18:18 +08:00
 | 1 xuanbg 2020-11-15 12:40:48 +08:00  1 如果统一都是这种……写个 map2List 转一下算了罢。为这个吵架没意义，要吵也要拉上技术负责人一起吵。 |
| 2 xuanbg 2020-11-15 12:44:13 +08:00 不过我很奇怪，他构造这么一个数据结构难道就不累么？明明用一个集合更直接更方便吧 |
 | 4 comsweetcs 2020-11-15 12:47:45 +08:00 6 ....格式能不能拍板好，看得都蛋疼。逻辑也不咋地，废话一堆。 |
6
cnbattle 2020-11-15 12:54:10 +08:00 via Android 统一就好……虽然我觉得这样有点不好
 | 7 lzlee 2020-11-15 12:55:31 +08:00 你说他不按格式, 那你的格式从哪里来的 如果你的依据是文档, 那他就是错了 如果你的依据不是文档, 那就立马整一个免得以后再扯皮 |
 | 8 lwlizhe OP @lzlee 额，没抓住重点……不是文档不文档的问题 可能是因为排版问题吧，那么省流精简版： 问题在于： 他把业务数据当作 key 放到 json 中返回…… PS：我认为这在任何一个业务、文档中都不该出现……在我看来 json 做为一种键值对数据，如果键值都不明确……那么怎么保证 value 准确稳定呢 |
| 9 lwlizhe OP |
 | 10 wxsm 2020-11-15 13:05:06 +08:00 via iPhone 马保国给了你多少钱，我海军学校给双倍 |
 | 11 redtea 2020-11-15 13:05:42 +08:00 这样的结构有个严重问题，顺序不可控。 |
 | 12 raaaaaar 2020-11-15 13:07:47 +08:00 via Android 文档呢？规范呢？ |
 | 13 watzds 2020-11-15 13:09:04 +08:00 via Android 你说不能处理，那我不敢苟同，是你前端技术不行 有缺点倒是真的 |
 | 15 cmdOptionKana 2020-11-15 13:15:33 +08:00 via Android 如果级比别对方低，不要直接找他理论，肯定说不通的，面子大于技术。应该向自己的上级反映问题。 如果与对方平级，直接开会定格式，定下来以后按格式办，不用管他是几年经验的大佬。 |
| 17 watzds 2020-11-15 13:28:12 +08:00 via Android 最大问题是用户名如果存在相同会覆盖 |
 | 18 Jooooooooo 2020-11-15 13:37:36 +08:00 你们的技术方案评审去哪了啊 |
 | 19 xiangyuecn 2020-11-15 13:47:19 +08:00 对方是老板亲戚，钱还比你多，忍忍吧 |
 | 20 hahasong 2020-11-15 13:54:59 +08:00 1 你耗子尾汁吧 |
 | 21 baylee12 2020-11-15 14:00:20 +08:00 1 商量着来呗，你这个数据可能是整个对象的一部分。你只要这两个值，他又不想单独再写个 vo 来存储，那就 json 一把梭咯。小公司就这样咯，我一般前端要什么格式，我就给什么格式。和气生财嘛，毕竟摸鱼才是赚钱，写代码是交易。打工人何必为难打工人 |
 | 22 muzuiget 2020-11-15 14:01:58 +08:00 2 后端那种可以保证用户名不会重复，你那种能够保持顺序，哪种匹配业务就用哪种，哪有什么标准不标准。 这种问题也值得吵，说明历练不够，收到数据自己转换一下就完事了，toMap 还是 toList，一行代码的事。 再说能表示同样信息量的情况下，我站后端，毕竟服务端内存比客户端金贵，再转换一次纯粹多余。 |
 | 23 binux 2020-11-15 14:03:47 +08:00 via Android |
 | 24 HongJay 2020-11-15 14:13:35 +08:00 以后不要犯这种聪明吧 |
| 27 baylee12 2020-11-15 14:22:15 +08:00 @muzuiget 这个不能这么说，毕竟现在前后端都有水货，我遇到过一个前端，vue 自定义 post 表单都不会，他说他们组内规范只有 get 和 post json，能怎么办，改下方法限制咯。我现在就很佛系了，又不是不能用。省下撕逼的时候，摸摸鱼，逛逛论坛，学点自己感兴趣的东西还是挺香的 |
| 29 lwlizhe OP |
| 30 lwlizhe OP @billlee 对了突然想起来 如果单独只针对键值对，那肯定是没问题的&…… 但是我说的语境是 json 中的键值对…… 不知道你是不是跟上面一个明确支持把业务数据当 key 值的家伙一样……所以现在回复下，如果你明确表明把业务数据当 key 值的话，当我没回复过…… |
 | 31 syozzz 2020-11-15 15:06:12 +08:00 他不讲武德啊 |
 | 32 billlee 2020-11-15 15:07:59 +08:00 @lwlizhe #30 大概理解了，List<Mode> 适合 orm 和页面的映射，Map<Key, Model> 适合计算。我这里后端只管复杂业务的计算，简单的 orm 是 node.js 负责的，所以更多使用的是 Map<Key, Model> 方案。 |
 | 33 sugars PRO 看到后端问题，我就啪的一下进来了，很快啊 |
 | 34 iApp 2020-11-15 15:26:40 +08:00 这个我肯定直接就转了,后台返回啥,前端处理啥,懒得扯蛋,浪费时间,又不是做不了 |
 | 35 imdong 2020-11-15 15:33:00 +08:00 我特别好说话，你给啥，我用啥，你要啥，我给啥。 只要你不是一天一个样，怎么开心怎么来。 好说话的咱就商量下，不好说话的咱就当无事发生。 |
 | 36 reus 2020-11-15 15:44:15 +08:00 传统开发以点到为止？ |
 | 37 Rect 2020-11-15 15:52:53 +08:00 看得脑壳痛 , 楼主能不能好好把一件事情讲清楚 |
 | 39 947211232 2020-11-15 16:25:48 +08:00 jsonObject：{"用户名 1"：1，"用户名 2"：2}， 这种很奇葩，如果是单一地方用，双方约定好就得 如果是全局的话，你还是跟上级反映吧，不利于扩展、维护的 |
 | 40 Kirsk 2020-11-15 16:46:52 +08:00 别洗 API 就应该以前端友好第一 |
 | 41 EminemW 2020-11-15 17:02:39 +08:00 via iPhone 不会吧，还有支持用 jsonObject：{"用户名 1"：1，"用户名 2"：2}这种的？该不会方法接收参数还用 map 吧 |
 | 42 smilingsun 2020-11-15 17:11:38 +08:00 看来 v 站蛮多人不看 b 站不看马保国的 |
 | 43 kooze 2020-11-15 17:14:24 +08:00 我猜后段是那个最好的语言开发的 |
 | 44 GoLand 2020-11-15 17:42:41 +08:00 这是小学语文没学好吗。。。。看半天除了楼主你自己还有谁能看明白你在说什么？发论坛上肯定希望大家一起讨论讨论，写的时候先考虑下是不是大家都能理解你这种火星文。 |
 | 45 labulaka521 2020-11-15 17:43:13 +08:00 via iPhone 回一句 希望你耗子尾汁 |
 | 46 dustinth 2020-11-15 17:59:21 +08:00 后端返回这个格式除非是极端要求通信性能的情况(比如返回几千几百个), 都是不合适的: Map 支持不了顺序的语义(返回 List 如果要求顺序呢?), Map 支持单个 entity 的语义上也不清晰(如果返回信息是 getByID 要么返回一个 Entity 要么为空); |
| 47 lwlizhe OP |
 | 48 CantSee 2020-11-15 18:52:47 +08:00 默认用 rest 格式的返回信息 后台就行 int httpstatus;String msg; <T> data; 返回统一 json |
 | 49 jhdxr 2020-11-15 21:56:20 +08:00 还是得看场景，如果说是要确保用户名（或者其他作为 key 的字段）唯一的场景下，明显 Map 比 List 合适。 |
 | 50 Orenoid 2020-11-15 22:17:01 +08:00 我有写过一两次这种接口，不过事先问了前端。因为当时那个接口如果以这种形式返回，只要一两行代码，要转换的话会特别繁琐……我实在不想处理，问了下前端，前端也没意见，就那么返回了。 |
 | 51 danielzh 2020-11-15 23:18:44 +08:00 据我知道。PHP 这种数据结构简单、且动态解析数据的后端语言，喜欢用这种业务 ID 为 key 的结构。 （重点：对于 PHP 来说用起来非常方便，像你提到的实体，PHP 涉及很少） 所以有相当一部分 PHP 后端，认为就应该带 Key 。 但对于不希望包含太多数据处理逻辑的前端来说，喜欢后者，后者的结构也跟语言相关。 我之前写 PHP 的时候，会专门写一个数据转换方法，按照前端格式转换一下，对双方都好维护。 |
| 52 danielzh 2020-11-15 23:23:12 +08:00 接上文。我从技术的角度分析下，为啥 PHP 喜欢这样。 1 、后端算出来结果长这样： 一个数组：["用户名 1":1, "用户名 2": 2] 2 、调用 PHP 语言的解析为 JSON 对象后： {"用户名 1"：1，"用户名 2"：2} 3 、如果转换成前端期望的结果： [{"userName":"用户名 1"，"value":1},{"userName":"用户名 2"，"value":2}] 需要将上文的数组，先做一次循环转换才行。所以后端会觉得复杂。 |
 | 53 Ptu2sha 2020-11-15 23:27:42 +08:00 哈哈 前端很无语 没有 key 不香 |
 | 54 nexo 2020-11-15 23:44:18 +08:00 耗子尾汁 doge |
 | 55 xfcy 2020-11-16 00:27:22 +08:00 我写了好多年 php 也不喜欢这种方式啊 |
 | 56 oppoic 2020-11-16 00:33:33 +08:00 via iPhone 互相尊重，商量着来。合作几次之后，公司哪个前端最靠谱你肯定心里有数了，再有项目点名要他即可。实在不行自己做前端咯 |
 | 57 bilibilifi 2020-11-16 05:47:31 +08:00 via iPhone 也就是说计算结果没有对应的 class，那么一些类的特殊限制他都是手动实现而不使用工具链吗？ |
 | 58 ztxcccc 2020-11-16 08:07:37 +08:00 1 这帖子我绝对每年看一次 |
 | 59 calmlyman 2020-11-16 08:36:59 +08:00 看来是训练有素，有备而来啊 |
 | 60 kltt22 2020-11-16 08:54:20 +08:00 语死早，看起来好费劲。 @danielzh 你是怎么知道 PHP 喜欢这样返回的？ PHP 的数据都是[{"userName":"用户名 1"，"value":1},{"userName":"用户名 2"，"value":2}]这种格式的，PHP 处理数组的方法一箩筐，还搞不定这样的小场面？ PHP 简单易用不是浪得虚名的。反而是 JAVA，做完运算还要筛掉空值的，用 C#对接的时候，没有完整版文档光凭返回值做实体类，不是少这个就是少那个，别扭的要死。 |
 | 61 Exceptionluo 2020-11-16 09:14:02 +08:00 “我一说他啪就站起来了，很快啊，然后上来就是” |
 | 62 szuwl 2020-11-16 09:18:24 +08:00 不会吧，都 0202 年了，还有人后端用 jsonobject 作为返回值对象吗 |
 | 63 oldbaby 2020-11-16 09:19:58 +08:00 这其实不算不按格式来给数据,真正恶心的是,给的数据不在同一个接口里,前端为了完整的数据,需要同时请求 N 个接口,然后还要 Promise.all 的成功回调才能拼接到完整的数据,后端拿钱不干活,多写一个接口都觉得累,只考虑服务器,不考虑客户端网络请求并行数量,失败率等问题 |
 | 64 NjcyNzMzNDQ3 2020-11-16 09:20:30 +08:00 来了来了，又一个语言黑。#52 |
 | 65 wangritian 2020-11-16 09:25:32 +08:00 必须用 array，map 会导致某些语言乱序，比如 go |
 | 66 danyi 2020-11-16 09:37:28 +08:00 大 E 了啊 |
 | 67 pph7y 2020-11-16 09:45:36 +08:00 这种还不如直接返回字符串用分割符号分开 |
 | 68 clf 2020-11-16 09:54:20 +08:00 array 和 map 返回的最大问题还是在一个 key 的可重复性（不过很少会遇到）和顺序上。如果后端没用有序的 map，则会造成前端乱序。 |
 | 69 withoutconscious 2020-11-16 09:57:37 +08:00 婷婷呢 |
 | 70 myCupOfTea 2020-11-16 10:02:21 +08:00 @redtea 是的,顺序不可控,这么干挺那啥的 |
 | 71 qumingkunnan 2020-11-16 10:12:16 +08:00 格式？谁定的？如果没有定规范就不能说他不按格式来了，定了规范就直接打回去不接收 |
 | 72 bonfy 2020-11-16 10:17:57 +08:00 其实就是文档嘛，当时接口定义返回这种格式，那人家没错 如果没文档，那你们继续吵吧，反正模糊地带，解决不了就上升 |
 | 73 PEAL 2020-11-16 10:50:04 +08:00 这样子写损失了顺序，而且有重复的风险 |
 | 74 rodrick 2020-11-16 11:02:05 +08:00 老马保国了，首先有咩有没文档，没有的话都是扯皮，其次这种写法确实操蛋，{name:"xiaoming",age:18}这种写法不是学前后端交互第一节课就该知道的么，但是这人不讲理的话那也没辙，很多事不是技术层面的问题，是人的问题 |
 | 75 yujieyu7 2020-11-16 11:02:38 +08:00 你的方案更好点，前端也更方便使用。不过，这格式转换前端和后端都是一个 function 解决的事，他听就听，不听就拉倒。出来挣钱嘛，开心最重要，有这撕逼的时间，改都改好了。 |
 | 77 darknoll 2020-11-16 11:52:26 +08:00 我遇到这种情况我就会去直接改他的代码，然后久而久之他的代码他可能自己就看不太懂了，就很可能来骂我，然后我就会去揍他 |
 | 78 ElmerZhang 2020-11-16 12:07:54 +08:00 @kltt22 @danielzh 作为一名写过 10 几年 PHP 的老程序员，我可以证明确实很多用 PHP 的喜欢这样写。 而且 PHP 还有个函数可以非常方便的把 List 转为这种 Map : array_column 用法见官方文档 Example 2: https://www.php.net/manual/en/function.array-column.php#example-5378 |
 | 79 goldenCold 2020-11-16 12:12:10 +08:00 可以说这样你不方便然后让他最好转一下。 没有规范的情况下确实怎么返回都行，没写过前端的后端有时候是会返回一些奇奇怪怪的格式 |
 | 80 coloz 2020-11-16 12:36:04 +08:00 我遇到更奇葩的是，同一个项目，有些接口是 list 返回，有些是对象返回，项目的管理让几个开发人员自己定，然后大家各写各的风格。 |
| 81 danielzh 2020-11-16 14:01:00 +08:00 @ElmerZhang 嗯嗯～ 有一样体会。 |
 | 82 stevenkang 2020-11-16 14:04:42 +08:00 同后端，只想知道，在代码规范中禁止用 map/json 的情况下，如何写出题主这样的结构 |
 | 83 fengpan567 2020-11-16 17:53:30 +08:00 又来了，这种帖子 |
 | 84 duxinglangzi 2020-11-16 18:05:39 +08:00 这特么的 喷他啊， 我作为一个后端都看不下去了 。 |
 | 85 yaoye555 2020-11-16 18:08:52 +08:00 劝你耗子尾汁,好好说话,别再犯这种聪明,小聪明啊! |
 | 86 kaiki 2020-11-16 18:14:36 +08:00 看他返回的这个，我真的想给他一个左正蹬，一个右鞭腿，一个左刺拳。 这东西拿到手怎么用嘛？ |
 | 87 netnr 2020-11-16 18:41:55 +08:00 via Android 这种格式也是可以的，很符合肉多骨少 |
 | 88 lithium4010 2020-11-16 18:58:50 +08:00 看场景的，这种数据结构如果用来做基于 用户名 的键值对检索的话效率比较高 |
 | 89 wangtian2020 2020-11-18 14:32:21 +08:00 动态变化的用第一种，非常少见。比如说我有一个表格结构，列的数量是动态的，先获取动态列的信息，再获取表数据。 99%的接口都用第二种 |
Select Language