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

Question

假设 API 有详细的文档记录，并且描述了每个可能的响应字段。

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

我试图计算像 Twitter 这样的大型应用减少的流量，这些数字实际上很有说服力。

例如:如果您从每个 API 响应中排除一个响应字段 "someGenericProperty":null，它是 26 字节，而据报道 Twitter 每天有 130 亿个 API 请求，流量减少量将 >300 Gb。

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

Answer 1

一般来说，不会。 API 越公开，API 的潜在消费者越多，API 的不变性就应该越大。

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

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

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

一如既往，有一百万个异常(exception)。我曾经面试过一家鱼雷维修设施的工作。他们的射程上有水下传感器来跟踪鱼雷。所有传感器数据都通过声学调制解调器中继到中央水下数据收集器。声学水下调制解调器？是的。在 300 波特率下，每个字节都很重要。

有电池供电的嵌入式应用，每个字节都很重要，还有低频 RF 通信系统。

另一个异常(exception)是稀疏数据。例如，想象一个具有 4,000,000 行和 10,000 列的矩阵，其中 99.99% 的矩阵值都是零。矩阵应该用不包含零的稀疏数据结构表示。