请求量巨大的情况下，缩短 API 字段单词长度是否值得？

[brader]

我曾经有关注过火币还是币安来着，他们的 API 接口，经历过改革，想和大家讨论一下。

首先可确定的是，这个网站的接口请求量非常巨大，这是毋庸置疑的。

最开始我看到他们的接口和我们平时的也差不多，后来我发现他们把 API 接口改了，如 {"c":0, "m":"xxx", "r":{"q":"xxx"}}，基本上每个字段都是一个字母，不够用了就两个字母。

我个人琢磨猜测了一下，他们这么干的目的，应该是想减少传输量（为什么我不觉得他们是想迷惑别人呢，因为他们有一些公开的 API ，也是这么设计的，文档也是开放出来的），也算是提高并发能力的一个技巧了。当然这么干坏处就是对接使用的人挺麻烦的，不看文档压根不知道什么意思，好处就是传输量实实在在的减少了，虽然一个接口减少的流量看似不多，但是以他们网站的规模来看，减少的量就很可观了。

大家觉得，如果是为了减少传输量这么干，是值得还是不值得，就是收益大？还是得不偿失？

[felixlong]

@brader 也不矛盾。估计他们所有的 API 都是这样混淆过的。至于文档，他们肯定是选择性的公开。然后那个文档是基于当前实现来写的。可能先有代码，然后混淆，运营一段时间。再从里面选择部分 API 写成文档来公开。

[hronro]

说实话，如何这真的是为了节省带宽，我觉得这就是拍脑袋的设计。上了 GZIP 之后，这种缩短字段带来的收益太小，而维护成本却大幅提高

[fkdog]

我觉得如果真的想缩短传输量，为什么不直接上 protobuf 这类结构体？
连字段名都可以省略

[nicholasxuu]

看规模算算呗，一年真的可能能省几十万。1GB 流量 0.5-0.8 元 /GB 。缩短 key 能省的只是皮毛倒是咯。

[LeegoYih]

响应的结果还是 JSON ，提升不了多少。既然都打算压缩了，不如前后端约定好一个协议，用非结构化的报文，不然没什么意义。

[tcfenix]

json 的优点是对人类友好, 如果不需要这个优点就是希望减少传输数据量的话直接上 pb 或者自己弄个私有协议不是更好....

[dcsuibian]

程序员的时间是值钱的

[wellsc]

缓缓打出一个问号

[lawler]

没做过巨量流量意识不到这个收益的大小。

七八年前，参加的一个 salon ，有百度的技术负责人讲到。
百度大部分时刻首页流量每秒在 1T~2T 。在已经极端压缩优化 js ，css 的前提下。又删减了一个字符，流量下降 1.5G~3G/s 。

[XiLingHost]

如果要削减流量，为啥还用 json 而不用二进制呢

[freshmanc]

也算混淆了、、

[lixintcwdsg]

自己上阿里云买个服务器，选流量的时候自己看看 1M ，100M 的贷款价格就好了呀。
实际上服务器真没几个钱，钱都花在流量上了～
尤其是高并发的服务，逻辑都简单

[akira]

@XiLingHost 应该是各方面妥协的产物

[glovebx]

大流量下收益肯定大，而且都有插件可以自动解决，不影响编码和调试效率

[shot]

@lawler #29

> 百度大部分时刻首页流量每秒在 1T~2T 。在已经极端压缩优化 js ，css 的前提下。又删减了一个字符，流量下降 1.5G~3G/s 。

姑且不考虑 gzip 压缩传输，一个 UTF-8 字符 1 byte ，1.5 Gbit ÷ 8 byte / bit = 7.5 × 10⁸。
10 亿量级的 QPS ，相当于全中国人民每一秒钟都刷一次百度首页。这不太客观吧。

如果考虑 gzip ，压缩之后更不应该会有显著区别了。

[shot]

@shot #35

呃……算错了。

1.5 Gbit ÷ 8 byte / bit ≈ 2 × 10⁸，相当于全中国人民每十秒钟都刷一次百度首页。

[p23XnFNH1Wq953rV]

量大值得, 省服务器流量也省客户端流量

[jones2000]

@starrys 这 Key ，value 哪里节省资源了， 导出都是 f1, f2 。。。。。 还不如 f1:[], f2:[] ..... 这样节省资源了， 只不过这样搞，前端转换麻烦点。

[xinshidai]

有代码转换器呢?

[realpg]

@shot #35
真干过大规模运维就知道,gzip 在 api 这种小数据量场景没卵用
很少见谁家 api 能过 2KB 的内容的
小内容再开 gzip 就是负优化
而普遍的 gzip 启用标准是 4KB, 这是一个充分权衡后对大多数场合很恰当的阈值