Web应用程序的服务器API是否会在JSON响应中排除空字段以降低流量？这是一个好主意吗？
我正在尝试计算一个像Twitter这样的大型应用程序的流量减少,而这些数字实际上相当令人信服.
例如：如果您排除单个响应字段,则“someGenericProperty”：null,即每个API响应的26个字节,而Twitter据报每天拥有130亿个API请求,流量减少量将> 300 GB.
每天超过300Gb的流量是相当省钱的,不是吗？这可能是最天真和简单的计算,但仍然.
解决方法
>开始使用API的开发人员在一个字段显示一段时间时会感到困惑,但并不是其他时间.这导致了沮丧,最终以支持请求的形式浪费了API所有者的时间.
>没有办法知道下游消费者如何使用API.通常,它们不像API开发人员想象的那样使用它.基于上下文出现或消失的元素可能会破坏使用API的应用程序. API开发人员通常无法知道下游应用程序何时被破坏,缺少来自下游开发人员的投诉.
>当数据元素出现或消失时,引入不确定性.数据元素是否未被发送,因为API认为它是无关紧要的？还是API本身改变了？还是消费者的代码中的一些错误不正确解析响应？如果消费者期望一个领域,而不是那里,那么如何被调试？
>在服务器端,需要额外的代码从响应中删除这些字段.如果删除数据的逻辑错了怎么办？这是一个注入缺陷的机会,这意味着有更多的代码必须维护.
在许多应用中,网络延迟是主要因素,而不是带宽.出于性能原因,许多API开发人员将会通过许多小的请求/响应来支持一些大的请求/响应.在我最后一家公司,销售和计费系统将定期交换100 KB,200 KB或更多的消息.有时只需要几KB的数据.但是,整体系统性能优于获取一些数据,发现需要更多的数据,然后发送对该数据的附加请求.
对于大多数应用来说,一些不一致性比多余数据浪费更危险.
一如以往,有一百万例外.我曾经在鱼雷维修设施上采访了一份工作.他们在他们的射击范围内有水下传感器来跟踪鱼雷.所有传感器数据通过声调制解调器中继到中央水下数据采集器.声学水下调制解调器？是.在300波特,每个字节计数.
每个字节都有电池供电的嵌入式应用,以及低频RF通信系统.
另一个例外是稀疏数据.例如,假设一个具有4,000,000行和10,000列的矩阵,其中99.99％的矩阵值为零.矩阵应用不包括零的稀疏数据结构来表示.
