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

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
}

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

谢谢

score 1 · Accepted Answer

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

score 0 · Accepted Answer

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

小心！这两种表示并不完全等价。 <DOB/>表示一个空元素；它相当于<DOB></DOB>。Empty 和 null 通常不能互换 - 这就是为什么我们同时拥有204 No Contentand 404 Not Found，同时拥有-sand的原因-e。

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

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

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

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

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

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

2 回答 2