在基于 REST 的服务中序列化空属性的行业标准是什么？答案

【问题标题】：What is the industry standard in serializing null attributes in REST based services?在基于 REST 的服务中序列化空属性的行业标准是什么？
【发布时间】：2019-05-29 05:06:34
【问题描述】：

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

我同事的论点是包含 JSON/XML 中定义的所有属性/元素，无论是否有价值。

理想情况下，它就像

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

同样

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

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

谢谢

【问题讨论】：

标签： json xml rest standards

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

小心！这两种表示并不完全等价。 <DOB/> 表示empty element；它相当于<DOB></DOB>。 Empty 和 null 通常不能互换 - 这就是我们同时拥有 204 No Content 和 404 Not Found、-s 和 -e 的原因。

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

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

在分布式系统中，客户端和服务器以不同的节奏部署，extend 在合约的生命周期内具有附加语义的模式很常见。但是如果客户端和服务器是独立部署的，你会遇到客户端和服务器理解相同模式的不同版本的情况。因此，我们需要注意前向和后向兼容性，以及保持一切正常所需的更改约束。

（当然，我们最终会想要做出不兼容的更改。所以我们需要引入一个新的消息模式，这反过来意味着我们需要考虑消息life cycles）。

这意味着，一般来说，我们需要为丢失任何可选字段做好准备——因为该消息可能是由在引入新字段之前只知道架构版本的进程生成的.

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

【讨论】：