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

[codeismylife]

A 同事：

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

B 同事：

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

我认为 B 写的是对的，但是不知道怎么科学地反驳 A。A 这么写好吗？不好的话 A 的问题在哪儿呢？

[xuanbg]

翻页！

[liuminghao233]

前端喜欢啥后端就反啥
反正没啥区别

[find2bHusky]

第一种写法的同事，一般命途多舛

[EscYezi]

话说没人问这个 json 是前端给后端还是后端给前端的吗？

[cheng6563]

完全看不懂第一种

[island205]

无非就是工作量和偷懒的问题

[cribug8080]

BBBBBBBBBBBBBBBBBBBBBBBBB

[719465553]

坚持用 a 的，应该是用 php 或者前端比较多的
b 的话应该是 java 或者同类型的程序员，或者适配过 java/android 的

[UnknownR]

转换下就知道是 B 比较好
https://imgur.com/a/TLCNXVx

[UnknownR]

@UnknownR
[Imgur]( )

[jakiepaper]

记得 wikipedia 的 api 接口是 A 风格，初看起来确实让人头大

[AngryMagikarp]

A 风格有毛病啊，如果把外面的[]去掉我还能理解，在最外面套一个[]是什么意思。

[rogi]

前几天后端也有返回类似 A 的 json 给我，我说能改成 B 这种风格的吗，他说不行好像说表还是什么不确定的就只能返回 A 给我了，其实前端都可以处理，可能是有什么难处才返回 A 给你的吧...

[fihserman123]

同样是映射关系，唯一的区别是逻辑上的.

[SHF]

A 好，查找方便

[yannxia]

讲道理···Docker Inspect 的 API 里面返回的 Json，就是 A 类型的，并不能说没有先例。

[lcsoul]

习惯 B 的方式

[a852695]

看情况吧，第一种 key-value 形式在找具体的详情时候很容易。但是列表展示就很蛋疼了。

[raysonlu]

一股脑说 phper 的，实事求是好吗？如果 ip 做主键，查找某个 ip，A 一下就能 hash 找到，B 的话还要遍历。php 除了['a'=>'l','b'=>'m','c'=>'n']，也有['l','m','n']，不同场景使用不同技术，单从技术层面鄙视的眼界也太低了吧

[beSimple]

猜拳，谁赢了听谁的

[shunfy]

如果 json 要求有序或者需要进行反序列化, 那就 B 吧。 否则, 随意。只要性能差别不是很大，没必要强行修改别人的编码习惯。

[shunfy]

追加下: 如果实在需要用字典, 又需要反序列化, 这里这样, 大不了损耗点内存和 CPU:
{
"192.168.1.2": {
"ip": "192.168.1.2",
"Memory": "10%",
"HardDisk": "25"
},
"192.168.1.1": {
"ip": "192.168.1.1",
"Memory": "25%",
"HardDisk": "10"
}
}

[jieyuanz24]

对接客户端角度来讲 B，A 这种情况只在极少数情况下会使用。

[Lonersun]

感觉 B 的兼容性更好些，哪天业务允许 ip 重复了，A 方案的结构就要改掉，对应 A 结构的业务处理代码全都要改，反而用 B 的话对原来代码几乎是没有影响的

[crist]

一句话：A 方式的数据都不能处理的前端 /后端都是辣鸡！

[allenframe]

A 本身设计就有问题，一个元素还要用[]括起来吗？

[lihongjie0209]

@crist #325 怎么把 A 转换成 Java PoJo?

[wwcxjun]

@719465553 PHP 真不背这锅。

[DoodleSit]

看业务吧
第一个是一个对象就够用了不用数组，根据 ip 取值比较好
第二个排序友好，但是不论是使用 filter 或者 map 取值，都需要遍历

[cloudfstrife]

跟据业务场景选择合适的数据结构真的很重要。
A：IP 不可以重复，方便跟据 IP 查找 msg，B:IP 可以重复，但是如果要查找特定 IP 的消息，需要遍历整个所有元素。
PS: A 外层真的需要一个数组吗？

[longxboy]

这个看场景的，又不是不能用，不要过度设计。
“如无必要，勿增实体” （ Entities should not be multiplied unnecessarily ），有时为了显示其权威性，人们也使用它原始的拉丁文形式：
Numquam ponenda est pluralitas sine necessitate.（避重趋轻）
Pluralitas non est ponenda sine necessitate.（避繁逐简）
Frustra fit per plura quod potest fieri per pauciora.（以简御繁）
Entia non sunt multiplicanda praeter necessitatem.（避虚就实）

[tommyZZM]

都不好，这样（手动 doge

```
[
["192.168.1.1", "10%", "25"],
["192.168.1.2", "25%", "10"]
]
```

[yannxia]

@lihongjie0209 Map<String, T>

[ILRan]

第一种还真遇到过。。。

[omysho]

@tommyZZM
这有什么？看我这种：
比较完整的数据（不常见）：
{
“1”: {
“1”: [1,2],
“2”: [1,2]
},
“2”: {
“1”: [1,2],
“2”: [1,2],
“3”: [1,2,3]
},
“3”: {
“1”:[1,2],
“2”:[1,2],
“4”:[1,2,3]
}
}

常见的不完整的数据：
{“1”:{“1”:[1]}}

PS: 没有文档

[deletemyself]

B A 这种别人查找处理都麻烦

[mythhack]

感觉 A 更好，方便取对应 ip 的具体数据

[trlove]

@lihongjie0209 并不是每个人都映射成 pojo 的 我维护的代码 太多人喜欢直接 JsonObject，根据 key 值去 get,因此 A 类型的 对于这种人来说 最方便 直接 get 自己想要的 ip 键值 ，B 类型 还得去遍历。 还是编码习惯问题

[lihongjie0209]

@trlove #338 写 Java 却喜欢用 JsonObject 或者是 Map 做参数本来就不是什么好习惯

[PandaQ]

恕我直言，A 同事是傻逼，尽量不要与他搭档

[PandaQ]

@PandaQ 补充一下针对移动端接口来说

[imbatjd]

专门注册一个账号。之前看到 dlsite 用的就是 A，因为网站特殊性不好意思说。现在又看到微软的 channel9 也用的是 A。其实我真的觉得奇怪，你们用的编程语言没有字典这个数据结构？还是有但是没办法遍历 Key ？怎么会有人说 A 取不出 IP 的？