假设API有很好的文档记录,并且描述了每个可能的响应字段。
Web应用程序的服务器API是否应该在JSON响应中排除空字段以降低流量?这是个好主意吗
我试图计算像Twitter这样的大型应用程序减少的流量,这些数字实际上相当令人信服。
举例来说:如果从每个API响应中排除一个响应字段"someGenericProperty":null
(26字节),而据报道Twitter每天有130亿个API请求,则流量减少量将>300 Gb。
每天减少300 GB以上的流量是相当省钱的,不是吗?这可能是有史以来最天真和最简单的计算,但仍然。
4条答案
按热度按时间j8yoct9x1#
一般来说,没有。API越公开,API的潜在消费者越多,API就应该越不变。
在许多应用中,网络延迟是主要因素,而不是带宽。出于性能原因,许多API开发人员倾向于使用一些大型请求/响应,而不是许多小型请求/响应。在我的上一家公司,销售和计费系统通常会交换100 KB、200 KB或更多的消息。有时只需要几KB的数据。但总体系统性能优于获取一些数据,发现需要更多数据,然后发送额外的数据请求。
对于大多数应用程序来说,一些不一致性比多余的数据浪费更危险。
一如既往,有一百万个例外。我曾经在鱼雷维修厂面试过一份工作。他们在射击场上有水下传感器来跟踪鱼雷。所有传感器数据都通过声学调制解调器中继到中央水下数据收集器。水声调制解调器?是的。在300波特时,每个字节都很重要。
有电池供电的嵌入式应用,每个字节都很重要,还有低频RF通信系统。
另一个例外是稀疏数据。例如,假设一个有4,000,000行和10,000列的矩阵,其中99.99%的矩阵值为零。矩阵应该用不包括零的稀疏数据结构表示。
eoigrqb62#
这个问题是错误的- JSON不是压缩或减少流量的最佳格式,但像谷歌protobuffer或bson这样的格式是。
我正在仔细地重新评估API方案中的空值。我们使用swagger(Open API),而json scheme并没有真正的可空类型,我认为这是有原因的。
如果你有一个JSON响应,它Map了一个突然为NULL的DB整数字段(或者根据DB方案),那么它确实适合关系DB,但对你的API来说一点也不健康。
我建议采用并遵循一种更优雅的方法,对于响应也是
to make better use of "required"
。如果该字段在响应API方案中是可选的,并且在数据库中具有空值,则不返回该字段。
我们还为API响应启用了严格的方案检查,这使我们能够更好地控制数据,并迫使我们不依赖API中的状态。
对于API客户端,这当然意味着要执行以下检查:
igsr9ssn3#
它肯定依赖于服务和它提供的数据量;它应该评估空/非空数据的比率,并设置一个阈值,超过排除这些元素的价值。谢谢分享,这对我来说是一个有趣的观点。
jpfvwuh44#
删除null属性
性能可能是一个原因,这取决于属性的数量和吞吐量,但还有其他几个令人信服的原因更倾向于省略属性。
1.单一类型优先于多个类型
引用another answer的话,“API越公开...... API就应该越不变。”(尽管这个答案在某种程度上违背了它自己的建议。)
想想这个:你会把属性设为字符串或数字吗?或使一个属性obbender或阵列?
一般来说,不,你不会。你通常只使用一种类型,除非有一个有意义的原因。
那么,为什么要将字段设置为String或NULL呢?
2.优先忽略不存在的值
你通常不会把null作为数组元素,为什么你会有null对象属性值?
3.易读性
阅读更多的信息比阅读更少的信息更困难。
4.创作
写更多的信息比写更少的信息更困难。
您更喜欢键入
{"a":1}
而不是{"a":1,"b":null,"c":null,"d":null}
。这一建议也在Google JSON样式指南中有所说明。