使JSON响应更小......只是一个想法

Question

只是一个想法......并且想知道Gzipped JSON是否已经涵盖了这一点.

但是说你在响应中有一个游戏对象列表:

game = {
    name: 'Randomer Quest!',
    description: 'Randomer's Quest is a brilliant game!',
    activated: true,
    points: 10,
    thumb: 'randomer-quest.jpg'
};

当你json_encode这个,它变成151 bytes:

{"games": [{"name":"Randomer Quest!","description":"Randomer's Quest is a brilliant game!","activated":true,"points":10,"thumb":"randomer-quest.jpg"}]}

好的......但是如果你有大约100个游戏的列表怎么办？这是关于13,913 bytes...但我们真的需要继续声明这些属性吗？我知道你可以解码它并循环它(神奇的)但是如果我们对它更加智能并在一个单独的对象中声明属性然后有一个数据数组呢？我们必须预先填充通常不存在的房产,但我仍然认为它值得.

像这样的东西:

{
"games": {
    p: ["name", "description", "activated", "points", "thumb"],
    d: [
        ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
        ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
    ]
}

}

P是属性,D是数组中的数据.之后我们有:9,377 bytes67%的大小!

好的,我知道你会说这没什么,但你确实看到的请求更像是40-100kb.我认为这是一个巨大的差异.有人用这样的东西吗？也许我们有自动执行此操作的工具？

32bitkid几乎已经说过,如果你打算这样做,你可能只需将其修剪为CSV格式......这是有意义的......那将是9,253 bytes66.5%左右.

"name", "description", "activated", "points", "thumb"
"Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"
"Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"

我已经看到大约100kb的JSON请求,这将变成66.5kb(失去33.5kb)

你怎么看？

大教堂

Answer 1

我同意这更紧凑.

{
    "games": {
        p: ["name", "description", "activated", "points", "thumb"],
        d: [
            ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
            ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
        ]
    }
}

但是等等,你可以进一步优化它,你真的需要"游戏"对象吗？这甚至更小!

{
    p: ["name", "description", "activated", "points", "thumb"],
    d: [
        ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
        ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
    ]
}

真的,最重要的是"p"和"d"以及包含的对象,我知道属性名称将是第一个,我的数据将是第二个？

[
    ["name", "description", "activated", "points", "thumb"],
    ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"],
    ["Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"]
]

那些数组和对象标记只是阻碍了,节省了几个字节!

"name", "description", "activated", "points", "thumb"
"Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"
"Randomer Quest!", "Randomer's Quest is a brilliant game!", true, 10, "randomer-quest.jpg"

等等......这种格式已经存在.它是CSV.它自1960年代中期以来一直存在.这也是为什么首先发明了XML和JSON的部分原因.JSON和XML为存储的对象增加了灵活性,并使它们比紧密压缩的二进制对象更易于阅读.您是否真的担心管道上的数据大小？如果你(如果那是,事实上,你的瓶颈)那么有很多不同的方法来解决这个问题.

但是,就个人而言,我认为你应该使用技术和工具来实现它们的目的,以及它们擅长做什么.

你正试图用一把锤子拧上一个螺丝......你会把它放在墙上,但对于任何一方来说它都不会很漂亮或令人愉快.

找到一种解决问题的模式,而不是相反.

Answer 2

根据经验,使用基于文本的格式背后的主要原因是它们对于人(使用简单的工具)来说易于阅读和调试.[例如,我认为XML对于大多数任务来说是一个巨大的禁忌].

关于我们为什么使用文本格式的一个相当古老的参考,虽然仍然值得认真阅读,但这是"Unix编程艺术"的这一章.

所以你必须瞄准清晰度,而不是尺寸.针对尺寸是过早优化的情况.

如果您担心带宽或存储,请考虑压缩数据.文本格式非常适合快速和强大的压缩,从技术上讲,它们在尺寸上并不逊色于二进制格式.此外,您可以方便地分离1 /表示数据的问题2 /有效地传输数据.

我不熟悉这个领域,但我已经准备好打赌有1/Javascript库用于压缩2 /系统方法在协议级别压缩数据.

最后,如果您担心性能,那么您宁愿有一个令人信服的理由(以及可靠的分析数据)来放弃基于文本的格式提供的舒适性.