Question

最近与我的同事讨论了适当的行业标准，以处理具有空值元素的XML / JSON格式共振。我的观点是，如果特定元素具有空值，则忽略/不包括XML和JSON响应中的元素。我的信念是，它将减少有效负载大小并减少传输带宽。

作为同事的论点是要包括JSON / XML中定义的所有属性/元素，无论是否有值。

所以理想情况下，就像

<name>John Doe</name>
 vs
<name>John Doe</name>
<DOB/>

类似地

{
  "name":"John Doe"
}
vs
{
   "name":"John Doe",
   "DOB":null
}

正确的方法是什么，为什么？

谢谢

Answer 1

可能没有正确或错误的方法，这取决于应用程序的要求。因此，Newtonsoft或ServiceStack允许您配置是否要包含空值。

Answer 2

<name>John Doe</name>
 vs
<name>John Doe</name>
<DOB/>

小心！这两种表示形式并不完全相同。 <DOB/>表示empty element；它等效于<DOB></DOB>。空和null通常不能互换-这就是为什么我们同时拥有204 No Content和404 Not Found的{{1}}和-s。

正确的方法是什么，为什么？

我相信您想在消息的更大范围内考虑这个问题。在理想的世界中，我们将拥有一个描述消息中每个字段的架构-字段的语义是什么，值的允许范围，哪些字段是必需的，哪些字段是可选的以及默认语义没有可选字段。

在客户端和服务器以不同节奏部署的分布式系统中，extend一种在合同有效期内具有附加语义的架构是很常见的。但是，如果客户端和服务器是独立部署的，则会出现客户端和服务器理解同一架构的不同版本的情况。因此，我们需要注意向前和向后的兼容性，以及为保持一切正常而对更改所做的限制。

（当然，我们最终将要进行不兼容的更改。因此，我们需要引入一个新的消息架构，这又意味着我们需要考虑消息life cycles）。

这意味着，通常，我们需要为丢失任何可选字段做好准备-因为消息可能是由仅在引入新字段之前了解架构版本的进程生成的

那么对于可选情况，知道可选字段的生产者是否应该始终将其包括在消息中？除了显式改进隐式的一般建议外，我不知道有任何支持这种观点的论点。