这是一个创建于 1487 天前的主题，其中的信息可能已经有所发展或是发生改变。
刚才有个朋友问我，发生什么事了，
我说怎么回事，给我发了几张截图，我一看，
嗷，原来是刚才，有一个高级后端，将业务数据做为 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
额……总之就是 16L 那俩链接的问题…………
看来这个问题是没有答案的……
不过我很喜欢 https://www.v2ex.com/t/629474?p=1 中 13L 的回复：
客户端看见 A 这种肯定要妈见打的
MD，人家这句说，不能再赞同了
看来这个问题是没有答案的……
不过我很喜欢 https://www.v2ex.com/t/629474?p=1 中 13L 的回复：
客户端看见 A 这种肯定要妈见打的
MD，人家这句说，不能再赞同了
 |
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
如果级比别对方低，不要直接找他理论，肯定说不通的，面子大于技术。应该向自己的上级反映问题。
如果与对方平级，直接开会定格式，定下来以后按格式办，不用管他是几年经验的大佬。 |
 |
16
debuggerx 2020-11-15 13:16:07 +08:00 1
|
|
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
以后不要犯这种聪明吧
|
 |
25
fansangg 2020-11-15 14:13:55 +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 2020-11-15 15:10:35 +08:00
看到后端问题，我就啪的一下进来了，很快啊
|
 |
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