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

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

在许多应用中，网络延迟是主要因素，而不是带宽。出于性能原因，许多API开发人员倾向于使用一些大型请求/响应，而不是许多小型请求/响应。在我的上一家公司，销售和计费系统通常会交换100 KB、200 KB或更多的消息。有时只需要几KB的数据。但总体系统性能优于获取一些数据，发现需要更多数据，然后发送额外的数据请求。
对于大多数应用程序来说，一些不一致性比多余的数据浪费更危险。
一如既往，有一百万个例外。我曾经在鱼雷维修厂面试过一份工作。他们在射击场上有水下传感器来跟踪鱼雷。所有传感器数据都通过声学调制解调器中继到中央水下数据收集器。水声调制解调器？是的。在300波特时，每个字节都很重要。
有电池供电的嵌入式应用，每个字节都很重要，还有低频RF通信系统。
另一个例外是稀疏数据。例如，假设一个有4，000，000行和10，000列的矩阵，其中99.99%的矩阵值为零。矩阵应该用不包括零的稀疏数据结构表示。

这个问题是错误的- 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客户端，这当然意味着要执行以下检查：

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

它肯定依赖于服务和它提供的数据量;它应该评估空/非空数据的比率，并设置一个阈值，超过排除这些元素的价值。谢谢分享，这对我来说是一个有趣的观点。

删除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样式指南中有所说明。