同事为了 JSON 怎么写吵起来了！请各位断案！

342 条回复 • 2019-12-28 23:33:44 +08:00

1 2 3 4

❮

❯

101

imn1

2019-12-16 16:32:32 +08:00

2

B 通用，A 适合 ip 做主键的场合

102

sherlockwhite

2019-12-16 16:35:06 +08:00

1

有一说一，PHPer 不背锅。

103

RickyC

2019-12-16 16:36:30 +08:00

建议 B 同事的答案

比如更改操作,

B 同事只要按照 key 去替换就可以了

而 A 同事需要
step1:删除掉原来的元素
step2:添加一个新的元素
如果是有序的表,还要有一个
step1.5: 找到原来元素的位置

104

libook

2019-12-16 16:37:02 +08:00

6

没有应用场景谈对错是没有意义的。

用于字典（映射）的话选 A （其实没必要放数组里了）；比如需要频繁地按照 IP 地址来取相关信息，此时用 A 方案能避免大量的循环语句。
用于呈现对象列表的话选 B ；比如返回一个服务器列表，迭代对列表里的每一台机器的信息做相应的处理。

两种我都经常用，没有啥绝对对和绝对错的，哪种合适就用哪种。

105

justforlook44444

2019-12-16 16:37:07 +08:00

json = javascript object notation

106

EurekaSeven

2019-12-16 16:37:09 +08:00 via Android

1

抛开应用场景谈对错都是耍流氓。

107

botian

2019-12-16 16:37:24 +08:00 via Android

B 的可扩展性比较好

108

GroupF

2019-12-16 16:37:55 +08:00

这个问题我不会，我直接给前端返回 B

109

sockpuppet9527

2019-12-16 16:38:26 +08:00

a 这样写不通用吧。。b 是通用的
这么说可能会挨打：比如我司写 c 要用 json 当 rpc 的 payload，a 这种解析很麻烦。。

110

GopherTT

2019-12-16 16:45:24 +08:00

我就想问 A 为什么多了个大括号..

111

linZ

2019-12-16 16:47:41 +08:00

@GopherTT 是对象，不是数组

112

qwerthhusn

2019-12-16 16:47:47 +08:00

3

A 是前端，B 是后端
前端总是想要啥处理都不用做直接用的数据
后端想从数据库返回后不做太多处理直接返回

113

ganbuliao

2019-12-16 16:48:16 +08:00

a 最大的问题应该就是排序的问题吧如果使用 jq 的 ajax 的话 json 会重新根据 key 排序
前端同学得到的数据应该是下面这样的吧
```
[
{

"192.168.1.1": {
"Memory": "25%",
"HardDisk": "10"
},
"192.168.1.2": {
"Memory": "10%",
"HardDisk": "25"
}
}
]
```

114

linZ

2019-12-16 16:48:37 +08:00

自己写的项目用 a，大家一起维护用 b

115

svenz

2019-12-16 16:54:21 +08:00

@qwerthhusn 想吐槽你几句想想算了黑前端黑上瘾了 A 这种输出结果最大的问题就是回到项目内大量的 hardcode 出现跟前后端没关系只跟水平和脑子有关系

116

wwcxjun

2019-12-16 16:54:34 +08:00

1

PHP 又背锅了... 我写 PHP 一直都是返回 B 的格式。

117

xuanbg

2019-12-16 16:56:51 +08:00

只用过 B 这种结构，A 这种兼职匪夷所思

118

weixiangzhe

2019-12-16 16:58:01 +08:00 via Android

如果是个 list 的话，a 放给前端转成 js 的对象后，在不同的浏览器里顺序会变

119

xinjiang

2019-12-16 17:00:15 +08:00

场景不同组装的数据结构不同，A 为 Map 型，B 为 Array 型，不比场景讨论有意义？

120

xinjiang

2019-12-16 17:05:57 +08:00

1

很明显 A 同事的数据结构是特定场景下进行了查找优化的，B 同事的数据结构当要进行频繁的查找时不用转成 Map 结构还怎么玩？

121

xinjiang

2019-12-16 17:06:23 +08:00

只是 A 外面的那个数组是完全没必要

122

deepred

2019-12-16 17:07:28 +08:00

A 有必要用数组吗？

123

linxl

2019-12-16 17:08:59 +08:00

A 这种客户端解析会不会很麻烦啊?

124

sonxzjw

2019-12-16 17:10:53 +08:00

数据结构服务于使用场景，没有场景作为前提，这样判断太武断了。如果你非要说哪个好的话

125

EastLord

2019-12-16 17:12:27 +08:00

我觉得要看使用场景，都没错

126

IamUNICODE

2019-12-16 17:13:12 +08:00

对接手机端肯定选 B，对接网页前端随便吧(个人觉得 B 更好)

127

back0893

2019-12-16 17:16:22 +08:00

1

关 php 啥子事,
java 或者 java 都能写出啊.

128

qzhai

2019-12-16 17:16:23 +08:00

b 永远都是对的使用的时候可以吧 B 转成 A。。。

129

burnings0506

2019-12-16 17:16:24 +08:00

A 连数组和对象都没搞明白。

130

index90

2019-12-16 17:19:39 +08:00

1

LZ 题目是不是写错了啊？
A 和 B 提供的数据结构说的不是一回事啊。A 的数组每个元素包含多个 IP 数据，而 B 的数组每个元素是一个 IP 数据，那么他们各自的数组分别代表什么？

131

shintendo

2019-12-16 17:20:26 +08:00

@qwerthhusn 别闹，前端才不想要 A 这么难用的结构

132

hbolive

2019-12-16 17:20:56 +08:00

一般情况下当然是 B 科学，A 以 IP 作为键值可能适合于某些特殊情况，但是为啥多一层{}？

133

lonelymarried

2019-12-16 17:23:14 +08:00

如果 ip 是唯一的，那么 a 的这么写也可以

134

swulling

2019-12-16 17:24:03 +08:00

[
{
"192.168.1.2": {
"ip": "192.168.1.1",
"Memory": "10%",
"HardDisk": "25"
},
"192.168.1.1": {
"ip": "192.168.1.1",
"Memory": "25%",
"HardDisk": "10"
}
}
]

完美

135

chent

2019-12-16 17:25:15 +08:00

看使用场景, A 作为 map 使用没必要套进数组.
有时候 A 根据 ip 取数据与判断什么的很方便, B 作为列表展示比较方便.
如果 B 要用元素内的 ip 做 k 取数据, 那就要转换回 A 的方式会更高效.
接口是为使用方服务的, AB 吵其实没意义, 要看谁用数据, 怎么用.

136

wodexiaogou

2019-12-16 17:25:26 +08:00

我为啥觉得 A 更好啊，更好理解，也更查询操作，比如获取某个服务器资源时，用 A 更方便，删除时也方便操作

137

kkjinping

2019-12-16 17:26:17 +08:00

选择 B 操作。

138

nomemo

2019-12-16 17:27:18 +08:00

看了楼上的回复，学习，总结了几点不用 A 的理由

1. key 不建议做可变值；
2. 多了一层解析嵌套；
3. 对象的含义发生了变化；

139

llcfays

2019-12-16 17:28:07 +08:00

不用担心，客户端同学会把 A 喷死的。

140

HongJay

2019-12-16 17:28:47 +08:00

哪个后台敢写 a 看我不打死他

141

mmqmyy

2019-12-16 17:29:18 +08:00

json 肯定要保持 k-v pairs 的一致性啊，不然你得校验多少东西？

142

index90

2019-12-16 17:31:17 +08:00

LZ 最好讲讲场景吧？看数据结构去猜的话，应该是一个批量写入 IP 数据的接口吧。
我比较站 A，A 作为接口数据描述更清晰，明确 IP 唯一，接口的定义越清晰，功能越单一越好。与前端对接的时候更需要这样。
B 更通用，后端程序员要考虑更多，接口需要更多书面描述来向使用者讲述接口要求，例如你要加多一句，“IP 不能重复，否者报错，balabala”

143

WantSleep

2019-12-16 17:32:15 +08:00

客户端解析 A 巨麻烦，序列化框架也不能用了

144

sunmker

2019-12-16 17:32:46 +08:00

键值对
键一般就那么几个选项，哪有变量当键的……

145

fyxtc

2019-12-16 17:33:43 +08:00

看来两位同事工作都不是很饱和啊

146

SY413927

2019-12-16 17:39:21 +08:00

非特殊情况，我选 B
假如不是我特别要求的情况下，后端小伙伴给我返回了 A 结构，他会被我打的很惨很惨

我是移动端。。。

147

TypeError

2019-12-16 17:40:56 +08:00 via Android

A 适合某些报表
大部分情况 B 够用

148

sdushn

2019-12-16 17:42:10 +08:00

客户端开发站 B，kv 写法解析起来很舒服，A 怎么解析？先解析字段名，放在 ip 字段里，再解析内容，有点反人类的逻辑。以上观点仅代表自己的想法

149

initer

2019-12-16 17:43:06 +08:00

移动端。我选 B。
A 不是不能解析。就是麻烦。

150

rumingruyue

2019-12-16 17:43:28 +08:00

B 更好解析，用的更多。
A 为啥用大括号包一下？还有必要用数组吗？

151

sdushn

2019-12-16 17:44:18 +08:00

emm，大概明白 A 的写法了，似乎不太适用于前端及客户端开发，使用场景很窄，B 基本是客户端开发的通用写法

152

liuy1994g

2019-12-16 17:45:54 +08:00 via Android

写成 192.168.1.2Memory, 192.168.1.2HardDisk 岂不是更好？

153

cedoo22

2019-12-16 17:48:11 +08:00

所以。。。。前端后端移动端的同学都会把 A 打死。。。。A 你还是自尽吧

154

ala2008

2019-12-16 17:53:15 +08:00

可以劝退 a：）

155

whypool

2019-12-16 17:54:23 +08:00

[
{
id:1,
name:'哈哈',
'哈哈':[
{a:123,c:345},
{a:555,c:666}
]
}
]

这样写会不会被砍死？

156

StarUDream

2019-12-16 18:08:45 +08:00

其实我想问一下，你们后端用的啥语言。

157

Mutoo

2019-12-16 18:16:21 +08:00

扁平化的结构更易于加工和组织，例如生成表，排序等。
字典不方便遍历，还需要手动转数组，并单独把 key 作为一个字段并入。
后端应该提供 B，而前端根据业务需要自行组织。

158

feigle

2019-12-16 18:18:19 +08:00

A:
如果知道 ip 的情况下，A 这种情况可以快速定位吧，只是多了个大括号。
B:
这种格式通用，不担心不关心业务。
在需要用 ip 定位的情况下，应该使用 A 格式，一般情况下用 B 格式

159

deplives

2019-12-16 18:18:34 +08:00 via iPhone

谁要是写 A 这样的给我用看我不把家里拖鞋拿来招呼他

160

IssacTomatoTan

2019-12-16 18:20:19 +08:00 via Android

A 不能直接存 mongo

161

LEX1994

2019-12-16 18:23:55 +08:00 via iPhone

b 结构简单

162

wanglufei

2019-12-16 18:24:50 +08:00 via Android

别用 json 了，protobuf flattenbuf 不香吗

163

shm7

2019-12-16 18:38:10 +08:00 via iPhone

@qwerthhusn 有点道理，写里面人家还要做空校验

164

yejianmail

2019-12-16 18:41:17 +08:00 via Android

我只能接受 B

165

ww2000e

2019-12-16 18:48:18 +08:00

我用 a 比较多，这才发现好多人不喜欢。。

166

jarnanchen

2019-12-16 18:48:34 +08:00

A 如果出现特殊情况了就很麻烦
比如 ip 重复，或者为 null 了

167

strongcoder

2019-12-16 18:49:12 +08:00 via iPhone

上一个这么搞的 A 被我们客户端开发打爆了

168

mansurx

2019-12-16 18:50:41 +08:00

插楼问一下，如果存 es 的话，应该是支持 B 的类型吧，不知道类型 A 支不支持

169

luozic

2019-12-16 18:52:19 +08:00

直接点，后面同一个 IP 下面再挂新东西咋表示？

170

guanhui07

2019-12-16 18:52:49 +08:00

B 好

171

hoyixi

2019-12-16 18:57:00 +08:00

个人觉得后者好些，前者如果 IP 字段发生变化，代码又得重新改

172

fgk

2019-12-16 19:10:56 +08:00

用了 ts 的话 B 可以定义很清晰的接口

173

zuokanyunqishi

2019-12-16 19:20:46 +08:00 via Android

1

PHP 表示不背这锅

174

lepig

2019-12-16 19:31:21 +08:00

BBBBBBBBBBBBBBBBBBBBBBBBBBBBB

175

zgq3337

2019-12-16 19:34:01 +08:00 via Android

压缩与展开的区别
类与函数的区别

176

Anarchy

2019-12-16 19:34:43 +08:00

A 省略了一个 Key 的信息，这就意味着解析方需要额外的工作补充这个 Key 信息。ORM 框架也需要完整信息才能做好映射

177

MonoLogueChi

2019-12-16 19:35:03 +08:00 via Android

个人认为 B 写的好一点，但是 A 写的用起来方便

178

answerhuang

2019-12-16 19:38:52 +08:00

数据传输用 B, 自己本地用的话, 转换成 A 格式.

179

sivacohan

2019-12-16 19:53:32 +08:00 via iPhone

@DOLLOR 你这个玩法我还是第一次见。挺有用的。

180

jzmws

2019-12-16 20:01:00 +08:00

b , a 的要是换个 ip 就 gg 了

181

hljjhb

2019-12-16 20:02:21 +08:00 via Android

B

elasticsearch 的 node stat api 就是 A 形式，很难受

182

wmwgijol28

2019-12-16 20:09:08 +08:00

屁大点事也能吵起来，直接问项目负责人用哪种结构完事

183

fanhed

2019-12-16 20:54:39 +08:00

B, 理由是每个字段可自描述

184

pepesii

2019-12-16 21:00:05 +08:00

两个我都用啊……

185

Jackxun123

2019-12-16 21:04:43 +08:00

不说需求就是耍流氓

186

TesterCC

2019-12-16 21:08:18 +08:00

关键你得说 A 和 B 为什么这么写，大家才好评论。如果 A、B 同级，那直接去找技术 leader 拍板就对了。

187

LemonFlower

2019-12-16 21:17:45 +08:00 via Android

(≖_≖ ) 如果 A 是 UniqueID 你们大概就不用吵了吧

188

sneezry

2019-12-16 21:37:59 +08:00

1

dynamic key 对静态类型语言太不友好了，无论当前技术栈如何，都尽量避免这么使用。对于 B 在检索上的劣势，通常可以再用一个 hash map 做辅助。

189

liuzhiyong

2019-12-16 21:55:14 +08:00

楼主说“我认为 B 写的是对的”，我也认为 B 的写法更好。

190

huobazi

2019-12-16 21:56:21 +08:00

赐 A 童鞋一丈绫吧

191

realpg

2019-12-16 21:58:02 +08:00

如果 A 的程序员不是一个智障的话那么我会站 A
我觉得他这么些一定是逻辑上 IP 地址有作为键的必要

192

uyhyygyug1234

2019-12-16 22:05:39 +08:00

b 是 excel 里面的表格 a 是 word 里面的表格。。。

193

daimubai

2019-12-16 22:25:33 +08:00 via iPhone

投 B 一票，值就是值，用作 key 不舒服

194

yilingersier

2019-12-16 22:27:33 +08:00

b, 如果把每个 obj=> arr, ip 当成 key，解析文件的时候做个 middleware，就和 A 一样了。。我是这么认为的，轻拍

195

CodeCore

2019-12-16 22:41:51 +08:00 via iPhone

@codeismylife A 的写法，Go 比较容易处理。。。其他语言麻烦吧？

196

mornlight

2019-12-16 22:47:06 +08:00 via iPhone

尽可能不要让 key 无法预测

197

bejond

2019-12-16 23:02:05 +08:00

A 最大问题是 key 不可控，数量和 key 值都不可控。这在做接口来看简直是灾难，直接导致客户端懵逼。如果是一个人的项目，自己想怎么来怎么来，但是商业项目，规范性和可维护性是很重要的实现要素。这也能说明为什么 java 比 js 比 python 笨重得多，但是仍然是排名靠前，项目最多的语言。并不是说它多好用，而在于它可控，换谁都能接着写。

198

AppxLite

2019-12-16 23:02:56 +08:00

B, A 就是一坨屎, 木办法同事都是返回 A 给我, 对接这种 api 就像吃屎一样.

199

T3RRY

2019-12-16 23:08:00 +08:00

服了，你竟然不知道如何喷 A ？

200

AppxLite

2019-12-16 23:15:55 +08:00

@qwerthhusn 我觉得刚好相反, 写惯前端的自然知道哪种风格的 api 好, 现实是, 后端因为各种原因, 或是懒, 或是 low, 写出一些恶心的 api.

1 2 3 4

❮

❯