后端不按格式返回数据的问题……

[lwlizhe]

刚才有个朋友问我，发生什么事了，

我说怎么回事，给我发了几张截图，我一看，

嗷，原来是刚才，有一个高级后端，将业务数据做为 key 返回给我……

（ 咳咳，举个例子：他返回的是直接一个 jsonObject：{"用户名 1"：1，"用户名 2"：2}，我当时还以为是类似于这种：[{"userName":"用户名 1"，"value":1},{"userName":"用户名 2"，"value":2}] ）

我说可以，我说是不是应该按格式来，这样不好用，

他不服气，我说大佬，你用这种方式返回数据，那怎么转成实体类呢？

我一说他啪就站起来了，很快啊，然后上来就是一句自己解析 json 数据不就行了，

我全部防出去了啊，防出去以后，自然是以商量的语气问下能不能以固定格式的方式，至少能转成实体类，这样大家都舒服，毕竟接口嘛，最好固定格式，这样无论从维护角度还是可用性来说都很不错的

结果他说我是有备而来的，这个只有四年工作经验，还是外包的年轻人不讲武德，来，骗，来，偷袭，他这个高级后端的老同志，这好吗？这不好，他劝我这位年轻人好自为之，好好反思，以后不要再犯这样的错误，小聪明啊，工作要以和为贵，要讲武德，不要搞窝里斗

咳咳，最后当然是以大佬说的为准，毕竟按他的说法

为什么你一定执着于这个非固定 key 这个 jsonobj 和 class 有什么不一样么？

以上纯属根据自身经历而来的逗乐吐槽……如有雷同冒犯，请轻喷~~~~

省流精简版：

后端把业务数据当作 key 值返回给展示端……

额……总之就是 16L 那俩链接的问题…………

看来这个问题是没有答案的……

不过我很喜欢 https://www.v2ex.com/t/629474?p=1 中 13L 的回复：


客户端看见 A 这种肯定要妈见打的


MD，人家这句说，不能再赞同了

[xuanbg]

如果统一都是这种……写个 map2List 转一下算了罢。为这个吵架没意义，要吵也要拉上技术负责人一起吵。

[xuanbg]

不过我很奇怪，他构造这么一个数据结构难道就不累么？明明用一个集合更直接更方便吧

[ila]

@xuanbg orm 返回的是数组

[comsweetcs]

....格式能不能拍板好，看得都蛋疼。逻辑也不咋地，废话一堆。

[xuanbg]

@ila 所以我才奇怪呀，把一个集合转成 map 不累么？

[cnbattle]

统一就好……虽然我觉得这样有点不好

[lzlee]

你说他不按格式, 那你的格式从哪里来的

如果你的依据是文档, 那他就是错了

如果你的依据不是文档, 那就立马整一个免得以后再扯皮

[lwlizhe]

@lzlee 额，没抓住重点……不是文档不文档的问题

可能是因为排版问题吧，那么省流精简版：

问题在于：

他把业务数据当作 key 放到 json 中返回……

PS：我认为这在任何一个业务、文档中都不该出现……在我看来 json 做为一种键值对数据，如果键值都不明确……那么怎么保证 value 准确稳定呢

[lwlizhe]

@comsweetcs 额……这就是盲目套用马保国语录的下场

看来我玩梗技术还有待提高啊，hhh

[wxsm]

马保国给了你多少钱，我海军学校给双倍

[redtea]

这样的结构有个严重问题，顺序不可控。

[raaaaaar]

文档呢？规范呢？

[watzds]

你说不能处理，那我不敢苟同，是你前端技术不行

有缺点倒是真的

[watzds]

@lwlizhe 什么叫 json 叫做键值对数据？ json 就是个对象序列化，不一定是键值对

[cmdOptionKana]

如果级比别对方低，不要直接找他理论，肯定说不通的，面子大于技术。应该向自己的上级反映问题。

如果与对方平级，直接开会定格式，定下来以后按格式办，不用管他是几年经验的大佬。

[debuggerx]

https://www.v2ex.com/t/629474
https://www.v2ex.com/t/643751

[watzds]

最大问题是用户名如果存在相同会覆盖

[Jooooooooo]

你们的技术方案评审去哪了啊

[xiangyuecn]

对方是老板亲戚，钱还比你多，忍忍吧😑

[hahasong]

你耗子尾汁吧

[baylee12]

商量着来呗，你这个数据可能是整个对象的一部分。你只要这两个值，他又不想单独再写个 vo 来存储，那就 json 一把梭咯。小公司就这样咯，我一般前端要什么格式，我就给什么格式。和气生财嘛，毕竟摸鱼才是赚钱，写代码是交易。打工人何必为难打工人

[muzuiget]

后端那种可以保证用户名不会重复，你那种能够保持顺序，哪种匹配业务就用哪种，哪有什么标准不标准。

这种问题也值得吵，说明历练不够，收到数据自己转换一下就完事了，toMap 还是 toList，一行代码的事。

再说能表示同样信息量的情况下，我站后端，毕竟服务端内存比客户端金贵，再转换一次纯粹多余。

[binux]

@watzds 如果语义就是用户名为 key 那就没问题。

归根到底这个问题看需求设计，不看你能不能转实体类。
能不能实现是你的问题，不是设计的问题。

[HongJay]

以后不要犯这种聪明吧

[fansangg]

我记得在贵站发的第一个帖子就是吐槽后端返回数据格式问题的
https://www.v2ex.com/t/479858
有兴趣可以看看现在的后端有多水

[billlee]

@lwlizhe #8 你是怎么理解键值对里面的键的？用户名本来就是自然主键，作为键值对里面的键完全没有问题

[baylee12]

@muzuiget 这个不能这么说，毕竟现在前后端都有水货，我遇到过一个前端，vue 自定义 post 表单都不会，他说他们组内规范只有 get 和 post json，能怎么办，改下方法限制咯。我现在就很佛系了，又不是不能用。省下撕逼的时候，摸摸鱼，逛逛论坛，学点自己感兴趣的东西还是挺香的

[baylee12]

@baylee12 时间

[lwlizhe]

@billlee 详见 16L 的那俩链接………………我感觉大家都说的很明确了

简单的来说就是，如果你就给我这个 json，其他什么都不知道

鬼知道那个用户名是啥玩意……

key 要明确含义啊……

[lwlizhe]

@billlee 对了突然想起来

如果单独只针对键值对，那肯定是没问题的&……

但是我说的语境是 json 中的键值对……

不知道你是不是跟上面一个明确支持把业务数据当 key 值的家伙一样……所以现在回复下，如果你明确表明把业务数据当 key 值的话，当我没回复过……

[syozzz]

他不讲武德啊

[billlee]

@lwlizhe #30 大概理解了，List<Mode> 适合 orm 和页面的映射，Map<Key, Model> 适合计算。我这里后端只管复杂业务的计算，简单的 orm 是 node.js 负责的，所以更多使用的是 Map<Key, Model> 方案。

[sugars]

看到后端问题，我就啪的一下进来了，很快啊

[iApp]

这个我肯定直接就转了,后台返回啥,前端处理啥,懒得扯蛋,浪费时间,又不是做不了

[imdong]

我特别好说话，你给啥，我用啥，你要啥，我给啥。

只要你不是一天一个样，怎么开心怎么来。

好说话的咱就商量下，不好说话的咱就当无事发生。

[reus]

传统开发以点到为止？

[Rect]

看得脑壳痛 , 楼主能不能好好把一件事情讲清楚

[ccppgo]

@imdong 老好人了

[947211232]

jsonObject：{"用户名 1"：1，"用户名 2"：2}，

这种很奇葩，如果是单一地方用，双方约定好就得

如果是全局的话，你还是跟上级反映吧，不利于扩展、维护的

[Kirsk]

别洗 API 就应该以前端友好第一

[EminemW]

不会吧，还有支持用 jsonObject：{"用户名 1"：1，"用户名 2"：2}这种的？该不会方法接收参数还用 map 吧

[smilingsun]

看来 v 站蛮多人不看 b 站不看马保国的🤣

[kooze]

我猜后段是那个最好的语言开发的

[GoLand]

这是小学语文没学好吗。。。。看半天除了楼主你自己还有谁能看明白你在说什么？发论坛上肯定希望大家一起讨论讨论，写的时候先考虑下是不是大家都能理解你这种火星文。

[labulaka521]

回一句 希望你耗子尾汁

[dustinth]

后端返回这个格式除非是极端要求通信性能的情况(比如返回几千几百个), 都是不合适的: Map 支持不了顺序的语义(返回 List 如果要求顺序呢?), Map 支持单个 entity 的语义上也不清晰(如果返回信息是 getByID 要么返回一个 Entity 要么为空);

[lwlizhe]

@GoLand 额，其实问题已经解决了……谁职级高谁说了算……

其实……我就来吐个槽的~~~~所以写的比较随性哈……见谅见谅，其实具体内容看 append 就行了

[CantSee]

默认用 rest 格式的返回信息 后台就行 int httpstatus;String msg; <T> data; 返回统一 json

[jhdxr]

还是得看场景，如果说是要确保用户名（或者其他作为 key 的字段）唯一的场景下，明显 Map 比 List 合适。

[Orenoid]

我有写过一两次这种接口，不过事先问了前端。因为当时那个接口如果以这种形式返回，只要一两行代码，要转换的话会特别繁琐……我实在不想处理，问了下前端，前端也没意见，就那么返回了。

[danielzh]

据我知道。PHP 这种数据结构简单、且动态解析数据的后端语言，喜欢用这种业务 ID 为 key 的结构。
（重点：对于 PHP 来说用起来非常方便，像你提到的实体，PHP 涉及很少）
所以有相当一部分 PHP 后端，认为就应该带 Key 。

但对于不希望包含太多数据处理逻辑的前端来说，喜欢后者，后者的结构也跟语言相关。
我之前写 PHP 的时候，会专门写一个数据转换方法，按照前端格式转换一下，对双方都好维护。

[danielzh]

接上文。我从技术的角度分析下，为啥 PHP 喜欢这样。
1 、后端算出来结果长这样：
一个数组：["用户名 1":1, "用户名 2": 2]
2 、调用 PHP 语言的解析为 JSON 对象后：
{"用户名 1"：1，"用户名 2"：2}
3 、如果转换成前端期望的结果：
[{"userName":"用户名 1"，"value":1},{"userName":"用户名 2"，"value":2}]
需要将上文的数组，先做一次循环转换才行。所以后端会觉得复杂。

[Ptu2sha]

哈哈 前端很无语 没有 key 不香

[nexo]

耗子尾汁 doge

[xfcy]

我写了好多年 php 也不喜欢这种方式啊

[oppoic]

互相尊重，商量着来。合作几次之后，公司哪个前端最靠谱你肯定心里有数了，再有项目点名要他即可。实在不行自己做前端咯

[bilibilifi]

也就是说计算结果没有对应的 class，那么一些类的特殊限制他都是手动实现而不使用工具链吗？

[ztxcccc]

这帖子我绝对每年看一次

[calmlyman]

看来是训练有素，有备而来啊

[kltt22]

语死早，看起来好费劲。
@danielzh
你是怎么知道 PHP 喜欢这样返回的？ PHP 的数据都是[{"userName":"用户名 1"，"value":1},{"userName":"用户名 2"，"value":2}]这种格式的，PHP 处理数组的方法一箩筐，还搞不定这样的小场面？ PHP 简单易用不是浪得虚名的。反而是 JAVA，做完运算还要筛掉空值的，用 C#对接的时候，没有完整版文档光凭返回值做实体类，不是少这个就是少那个，别扭的要死。

[Exceptionluo]

“我一说他啪就站起来了，很快啊，然后上来就是”😂😂😂

[szuwl]

不会吧，都 0202 年了，还有人后端用 jsonobject 作为返回值对象吗

[oldbaby]

这其实不算不按格式来给数据,真正恶心的是,给的数据不在同一个接口里,前端为了完整的数据,需要同时请求 N 个接口,然后还要 Promise.all 的成功回调才能拼接到完整的数据,后端拿钱不干活,多写一个接口都觉得累,只考虑服务器,不考虑客户端网络请求并行数量,失败率等问题

[NjcyNzMzNDQ3]

来了来了，又一个语言黑。#52

[wangritian]

必须用 array，map 会导致某些语言乱序，比如 go

[danyi]

大 E 了啊

[pph7y]

这种还不如直接返回字符串用分割符号分开

[clf]

array 和 map 返回的最大问题还是在一个 key 的可重复性（不过很少会遇到）和顺序上。如果后端没用有序的 map，则会造成前端乱序。

[withoutconscious]

婷婷呢

[myCupOfTea]

@redtea 是的,顺序不可控,这么干挺那啥的

[qumingkunnan]

格式？谁定的？如果没有定规范就不能说他不按格式来了，定了规范就直接打回去不接收

[bonfy]

其实就是文档嘛，当时接口定义返回这种格式，那人家没错

如果没文档，那你们继续吵吧，反正模糊地带，解决不了就上升

[PEAL]

这样子写损失了顺序，而且有重复的风险

[rodrick]

老马保国了，首先有咩有没文档，没有的话都是扯皮，其次这种写法确实操蛋，{name:"xiaoming",age:18}这种写法不是学前后端交互第一节课就该知道的么，但是这人不讲理的话那也没辙，很多事不是技术层面的问题，是人的问题

[yujieyu7]

你的方案更好点，前端也更方便使用。不过，这格式转换前端和后端都是一个 function 解决的事，他听就听，不听就拉倒。出来挣钱嘛，开心最重要，有这撕逼的时间，改都改好了。

[THESDZ]

@yujieyu7 #75 问题在于,大家都是红灯停,绿灯行,你整个绿灯停,红灯行,是没问题,但是不难受吗?

[darknoll]

我遇到这种情况我就会去直接改他的代码，然后久而久之他的代码他可能自己就看不太懂了，就很可能来骂我，然后我就会去揍他

[ElmerZhang]

@kltt22 @danielzh 作为一名写过 10 几年 PHP 的老程序员，我可以证明确实很多用 PHP 的喜欢这样写。
而且 PHP 还有个函数可以非常方便的把 List 转为这种 Map : array_column
用法见官方文档 Example 2: https://www.php.net/manual/en/function.array-column.php#example-5378

[goldenCold]

可以说这样你不方便然后让他最好转一下。 没有规范的情况下确实怎么返回都行，没写过前端的后端有时候是会返回一些奇奇怪怪的格式

[coloz]

我遇到更奇葩的是，同一个项目，有些接口是 list 返回，有些是对象返回，项目的管理让几个开发人员自己定，然后大家各写各的风格。

[danielzh]

@ElmerZhang 嗯嗯～ 有一样体会。

[stevenkang]

同后端，只想知道，在代码规范中禁止用 map/json 的情况下，如何写出题主这样的结构

[fengpan567]

又来了，这种帖子

[duxinglangzi]

这特么的 喷他啊， 我作为一个后端都看不下去了 。

[yaoye555]

劝你耗子尾汁,好好说话,别再犯这种聪明,小聪明啊!

[kaiki]

看他返回的这个，我真的想给他一个左正蹬，一个右鞭腿，一个左刺拳。
这东西拿到手怎么用嘛？

[netnr]

这种格式也是可以的，很符合肉多骨少

[lithium4010]

看场景的，这种数据结构如果用来做基于 用户名 的键值对检索的话效率比较高

[wangtian2020]

动态变化的用第一种，非常少见。比如说我有一个表格结构，列的数量是动态的，先获取动态列的信息，再获取表数据。
99%的接口都用第二种