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

概述让我们说API已经有很好的记录,并且描述了每一个可能的响应领域. Web应用程序的服务器API是否会在JSON响应中排除空字段以降低流量？这是一个好主意吗？ 我正在尝试计算一个像Twitter这样的大型应用程序的流量减少,而这些数字实际上相当令人信服. 例如：如果您排除单个响应字段,则“someGenericProperty”：null,即每个API响应的26个字节,而Twitter据报每天拥有1 让我们说API已经有很好的记录,并且描述了每一个可能的响应领域.

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

我正在尝试计算一个像Twitter这样的大型应用程序的流量减少,而这些数字实际上相当令人信服.

例如：如果您排除单个响应字段,则“someGenericProperty”：null,即每个API响应的26个字节,而Twitter据报每天拥有130亿个API请求,流量减少量将> 300 GB.

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

解决方法 一般来说,没有.越来越多的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％的矩阵值为零.矩阵应用不包括零的稀疏数据结构来表示.

总结

以上是内存溢出为你收集整理的从Web应用程序中的JSON服务器响应中排除空字段是否值得减少流量？全部内容，希望文章能够帮你解决从Web应用程序中的JSON服务器响应中排除空字段是否值得减少流量？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。