是否值得从Web应用程序中的JSON服务器响应中排除空字段以减少流量？

Question

假设API已有详细记录,并且描述了每个可能的响应字段.

Web应用程序的服务器API是否应在JSON响应中排除空字段以降低流量？这根本不是一个好主意吗？

我试图计算像Twitter这样的大型应用程序减少的流量,这些数字实际上非常有说服力.

例如:如果"someGenericProperty":null从每个单独的API响应中排除单个响应字段(26个字节),而据报道Twitter每天有130亿个API请求,则流量减少量将超过300 Gb.

每天超过300 Gb的流量是相当省钱的,不是吗？这可能是有史以来最天真,最简单的计算,但仍然如此.

Answer 1

一般来说,没有.API越公开,API的潜在消费者越多,API就越不变.

• 当某个字段出现一段时间而不是其他时间时,开始使用API​​的开发人员会感到困惑.这会导致沮丧并最终以支持请求的形式浪费API所有者的时间.
• 无法准确了解下游消费者如何使用API​​.通常,他们并没有像API开发人员想象的那样使用它.基于上下文出现或消失的元素可能会破坏使用API​​的应用程序.API开发人员通常无法知道下游应用程序何时被破坏,缺少下游开发人员的投诉.
• 当数据元素出现或消失时,会引入不确定性.数据元素是否未发送,因为API认为它不相关？或者API本身已更改？或者是消费者代码中的一些错误没有正确解析响应？如果消费者期望某个字段而不存在,那么如何进行调试？
• 在服务器端,需要额外的代码来从响应中去掉那些字段.如果删除数据错误的逻辑怎么办？这是一个注入缺陷的机会,这意味着必须维护更多的代码.

在许多应用中,网络延迟是主要因素,而不是带宽.出于性能原因,许多API开发人员会赞成针对许多小型请求/响应的一些大型请求/响应.在我上一家公司,销售和计费系统会定期交换100 KB,200 KB或更多的消息.有时只需要几KB的数据.但总体系统性能优于获取一些数据,发现需要更多数据然后发送额外的数据请求.

对于大多数应用程序而言,一些不一致性比多余数据浪费更危险.

与往常一样,有一百万例外.我曾经在鱼雷维修厂接受采访.他们在射程上有水下传感器来跟踪鱼雷.所有传感器数据都通过声学调制解调器传递到中央水下数据采集器.声学水下调制解调器？是.每波特300波特,每个字节都很重要.

有电池供电的嵌入式应用,每个字节都很重要,以及低频RF通信系统.

另一个例外是稀疏数据.例如,设想一个包含4,000,000行和10,000列的矩阵,其中99.99%的矩阵值为零.矩阵应该用不包含零的稀疏数据结构表示.