同事为了 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 的问题在哪儿呢？

[imn1]

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

[sherlockwhite]

有一说一，PHPer 不背锅。

[RickyC]

建议 B 同事的答案

比如更改操作,

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

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

[libook]

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

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

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

[justforlook44444]

json = javascript object notation

[EurekaSeven]

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

[botian]

B 的可扩展性比较好

[GroupF]

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

[sockpuppet9527]

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

[GopherTT]

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

[linZ]

@GopherTT 是对象，不是数组

[qwerthhusn]

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

[ganbuliao]

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

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

[linZ]

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

[svenz]

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

[wwcxjun]

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

[xuanbg]

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

[weixiangzhe]

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

[xinjiang]

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

[xinjiang]

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

[xinjiang]

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

[deepred]

A 有必要用数组吗？

[lazypu]

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

[sonxzjw]

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

[EastLord]

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

[IamUNICODE]

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

[back0893]

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

[qzhai]

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

[burnings0506]

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

[index90]

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

[shintendo]

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

[hbolive]

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

[lonelymarried]

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

[swulling]

[
{
"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"
}
}
]

完美

[chent]

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

[wodexiaogou]

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

[kkjinping]

选择 B 操作。

[nomemo]

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

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

[llcfays]

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

[HongJay]

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

[mmqmyy]

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

[index90]

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

[WantSleep]

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

[sunmker]

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

[hikarugo]

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

[SY413927]

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

我是移动端。。。

[TypeError]

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

[sdushn]

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

[initer]

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

[rumingruyue]

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

[sdushn]

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

[liuy1994g]

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

[dr1q65MfKFKHnJr6]

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

[ala2008]

可以劝退 a：）

[whypool]

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

这样写会不会被砍死？

[StarUDream]

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

[Mutoo]

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

[feigle]

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

[deplives]

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

[IssacTomatoTan]

A 不能直接存 mongo

[LEX1994]

b 结构简单

[wanglufei]

别用 json 了，protobuf flattenbuf 不香吗

[shm7]

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

[yejianmail]

我只能接受 B

[undefined8]

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

[4263Ad06Awk3b1Do]

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

[strongcoder]

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

[mansurx]

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

[luozic]

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

[guanhui07]

B 好

[hoyixi]

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

[fgk]

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

[zuokanyunqishi]

PHP 表示不背这锅

[lepig]

BBBBBBBBBBBBBBBBBBBBBBBBBBBBB

[zgq3337]

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

[Anarchy]

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

[MonoLogueChi]

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

[answerhuang]

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

[sivacohan]

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

[jzmws]

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

[hljjhb]

B

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

[wmwgijol28]

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

[fanhed]

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

[pepesii]

两个我都用啊……

[Jackxun123]

不说需求就是耍流氓

[TesterCC]

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

[LemonFlower]

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

[sneezry]

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

[liuzhiyong]

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

[huobazi]

赐 A 童鞋一丈绫吧

[realpg]

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

[uyhyygyug1234]

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

[daimubai]

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

[yilingersier]

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

[CodeCore]

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

[mornlight]

尽可能不要让 key 无法预测

[bejond]

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

[AppxLite]

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

[T3RRY]

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

[AppxLite]

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