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

我们可以说，API有很好的文档记录，并且描述了每个可能的响应字段

web应用程序的服务器API是否应该在JSON响应中排除空字段以降低通信量？这是个好主意吗

我试图计算像Twitter这样的大型应用程序减少的流量，这些数字实际上非常令人信服

例如：如果从每个API响应中排除单个响应字段，

“someGenericProperty”：null

，即26字节，而据报道Twitter每天有130亿个API请求，流量减少量将>300 Gb

---

每天减少300 Gb以上的流量是相当省钱的，不是吗？这可能是有史以来最幼稚、最简单的计算，但仍然如此。

这肯定取决于服务及其提供的数据量；应该评估空/非空数据的比率，并设置一个阈值，使其超过排除该元素的值。

---

谢谢分享，对我来说这是一个有趣的观点。

一般来说，不。API越公开，API的潜在消费者越多，API应该越稳定

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

在许多应用中，网络延迟是主要因素，而不是带宽。出于性能原因，许多API开发人员会倾向于使用一些大型请求/响应，而不是许多小型请求/响应。在我的上一家公司，销售和计费系统通常会交换100KB、200KB或更大的消息。有时只需要几KB的数据。但总体系统性能比获取一些数据要好，需要发现更多数据，然后再发送额外的数据请求

对于大多数应用程序来说，某些不一致性比多余的数据浪费更危险

和往常一样，有一百万个例外。我曾经面试过鱼雷维修厂的一份工作。他们在射程上有水下传感器来跟踪鱼雷。所有传感器数据通过声学调制解调器传输到中央水下数据采集器。水声调制解调器？对在300波特时，每个字节都计数

有电池供电的嵌入式应用程序，每个字节计数，以及低频射频通信系统

---

另一个例外是稀疏数据。例如，假设一个矩阵有4000000行和10000列，其中99.99%的矩阵值为零。矩阵应该用不包含零的稀疏数据结构表示。

问题出在错误的一边-JSON不是压缩或减少流量的最佳格式，但类似于google protobuffers或bson的格式

我现在正在仔细地重新评估API方案中的nullables。我们使用swagger（openapi），并没有像nullable类型这样的东西，我认为这是一个很好的理由

如果您有一个JSON响应映射一个突然为空的DB整数字段（或者可以根据DB方案），那么对于关系数据库来说确实可以，但对于API来说根本不健康

我建议采用并遵循一种更为优雅的方法，那就是

更好地使用“required”

作为响应

如果该字段在响应API方案中是可选的，并且在DB中具有空值，则不要返回该字段

我们还为API响应启用了严格的方案检查，这使我们能够更好地控制数据，并迫使我们不依赖API中的状态

对于API客户端，这当然意味着要进行如下检查：

if ("key" in response) {
    console.log("Optional key value:" + response[key]);
} else {
    console.log("Optional key not found");
}

---

如果没有列出字段，那么它就不是真正的合同。JSON响应应该是一个契约（强烈的意见，弱持有）。感谢您的评论！你能用某种来源来备份它吗？我试图在谷歌上搜索并阅读有关JSON格式规范的信息，但没有找到任何关于该合同的信息。JSON模式是一个契约，而不是响应数据本身。我没有任何来源，只是我在处理JSON API和处理大量第三方API方面的经验。这就是为什么我说这是一个很强的观点，但持弱观点。我也喜欢这个关于API语义的回答：