AJAX/JSON API 缩小？答案

【问题标题】：AJAX/JSON API minification?AJAX/JSON API 缩小？
【发布时间】：2016-04-14 05:31:55
【问题描述】：

许多 JSON / RESTful API 具有长而冗长的键名，占构成文件的大部分字节。

"profile_sidebar_border_color": "DFDFDF",
"profile_sidebar_fill_color": "F3F3F3",
"profile_text_color": "333333",
"profile_use_background_image": true,
"default_profile": false,
"default_profile_image": false,

这样做还需要在客户端文件中使用这些名称。

对于开发来说这很好，但对于生产来说，从服务器发送带有缩小（单字母）密钥的数据，然后在客户端重新膨胀似乎是有利可图的。

做得对，这可以在大型客户端库的缩小中减少数千字节，在 API 中减少 50% 以上。

是否存在用于此目的的库或解决方案？

【问题讨论】：

我考虑过的可能答案：没有必要，因为 Gzipping；会很好，但实施的难度超过了收益；或者收益并不是什么大不了的事。尽管如此，由于存在一些庞大的 API，这种缩小似乎很有用。
是的，我认为你低估了 gzip 的性能。我的一个朋友比较了各种压缩/压缩 JSON 数据的方法，包括 gzip，没有比 gzip 更好的了。不幸的是我找不到结果，也许他没有公开分享。
这里是：github.com/wincent/relay/blob/hack/contrib/lightweight-results/…

标签： json ajax rest http minify

【解决方案1】：

gzip 和 DEFLATE 算法已经以这种方式工作。它们应该已经分别存在于服务器层和每个主要的 Web 浏览器中。

不同之处在于它们不仅仅使用带有 JSON 的“a”或“b”或“c”等单字母键。他们使用不使用 JSON 的完整 ASCII 表映射。它使用除 a、b 和 c 之外的其他 ASCII 字符，如制表符、CR、LF、ACK、BEL 等……有些字符看起来像红心、梅花、菱形、黑桃、笑脸等……他们进一步优化 JSON，只使用其中每个字符中的一个 {}[]:",，而不是 JSON 中的重复字符：{{"a":"1","b":[2,"blue"]},{"c":"3"}]。

我们不需要运行 JS 库来使用它们。可能需要设置 Web 服务器以启用 gzip 压缩，但从我记得很久以前阅读的内容来看，默认情况下，每个浏览器都已启用 DEFLATE。当检测到 gzip'd 数据时会自动使用它。

这里是它们如何工作的快速概述： HTML + CSS + JS 字符由 Web 服务器使用 gzip 压缩成字典映射。因此，每个字符在该地图中只能表示一次。只有字典通过网络发送。不发送原始源代码。字典知道如何展开自身，回到原始源文件。所以它不使用任何 JS 映射关键字或函数，它们经常出现在任何 CSS 或 JS .map 文件中。

当浏览器使用 DEFLATE 算法时，它会将每个字典解映射（解压缩/膨胀）回一个可读的 HTML、CSS 或 JS 流。在客户端，浏览器显示解压后的字典图。这就是我们使用 F12 键在各种网络检查工具中看到的内容。这是一个无缝的压缩/解压过程，我们通常看不到。 DEFLATE 关键字有时可以在来自服务器的标头响应中看到。

检查您的网络服务器是否已使用 gzip 和 DEFLATE 算法。 LZ77 & LZ78 back-story 是一个有趣的起点，可以让您了解当今社会如何实现高速通信。似乎我们所有的缩小和压缩技术（互联网网页代码、图像文件格式、广播有线电视、手机信号塔数据传输等）都是建立在该研究之上的。 Gzip 只是LZW 的免费软件版本，其中LZW 用于Adobe Photoshop .tif 文件。对于“轻读”，这里是原始IEEE LZ77 whitepaper 的副本。

【讨论】：