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

[brader]

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

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

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

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

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

[vitovan]

如果可以提供组件，让客户端开发时可以直接调用，生成压缩后的请求包，应该还好。

不过这个问题主要看计划资源投入和话语权在谁手里。

我纯粹是瞎说两句。

[westoy]

服务端替换 key 变量也是要成本的啊， 我真不信他们开发是手撸写死这种变量。 数据传输也是最小包和对齐的， 省几个字节未必有实际用途的

这种接口命名更大的意义是避免语义化让你直接猜出用途吧.......

[wanguorui123]

开启 GZIP

[manecocomph]

程序现阶段还是给人看的. LB 后边能加几台机器能解决的问题, 人脑和电脑都做个 mapping 是不值得的. 从节省资源或总体性能的角度看上去收益不大.

[brader]

@westoy 你别说，他们还就可能是写死的，我就觉得，这么干得到的好处和付出的成本，值不值得，其实说到成本，他们也算是财大气粗了，估计不差钱。 然后关于你说的避免猜出用途，我前面也说了，我觉得应该不是，他们有公开的 API 的，公开 API 还提供文档给用户使用，也是设计的一个字母的

[brader]

@wanguorui123 gz 不用说的，他们网站都是专业的，已经打开了，浏览器本身支持，服务端 nginx 又支持，根本不需要应用层代码考虑这个东西，所以也就不讨论这个了

[deplivesb]

主要是为了防止被轻易猜出来字段属性吧。减少传输量？能减少几个字节？说不定还被对齐了。

[brader]

@deplivesb 防止猜出的话，就很矛盾啊，他们有公开 API ，还公布了文档，公开 API 也是这么设计的

[xiangyuecn]

10 年前我就是用的 c 、m 做 code 、message ，老铁 没毛病，这玩意最开始定义好了 就很难改了，反正都是 ctrl+c ctrl+v ，符号而已

[deplivesb]

@brader 那就是懒的取名字，节省传输量这个事儿没有这么做的。
我不知道你说他们接口的请求量巨大是有多巨大。
我司核心业务的中台接口日 pv 在 2.5 亿左右，应该也还算大吧，也没有靠这个减少传输量保证可靠性的。

[dougy592]

币安的 websocket 每秒都要向海量客户端推送大量行情 /交易数据，这样做可能真的是为了减少传输

[dougy592]

我的币安客户端，每个月要使用超 10Gb 流量

[gam2046]

protobuf 就是这么做的，key 都变成了索引，也就是一个数字，来压缩传输量。

[james2013]

币安是值得这么做的
api 订阅某个市场的行情数据，一天几十 G ，这还是单个用户，而且是免费提供

[crysislinux]

流量大的这么做的感觉也不少，比如 Google 也是这样

[levon]

咸吃萝卜淡操心

[starrys]

应该就是为了节省流量，尤其是更新频率很高的情形下。
另外的案例：

[mercury233]

这样缩短再 gzip 之后真的有效果吗……

[Jooooooooo]

为了节省那点根本察觉不到的流量不如把心思花在别的地方.

比如返回的字段是不是梳理梳理能减少一个?

[wyx119911]

这样只能省一点点吧，不如直接用 pb 二进制传输了