Json - 可选子文档

Json - optional subdocument

我从一个包含几个嵌套子文档的应用程序中得到 json。其中一些文件是可选的,并非始终存在。我想知道是否有处理此问题的最佳实践。

例如(该文档只是一个例子,真实的看起来不同,但我不能 post 它,例子是从:How to represent sub-documents in JSON array as Java Collection using Jackson? 复制的):Adreess 子文档并不存在于我收到的每个文档中。

 {
  "attributes": {
    "type": "Lead",
    "url": "/services/data/v30.0/sobjects/Lead/00Qi000000Jr44XEAR"
  },
  "Id": "00Qi000000Jr44XEAR",
  "Name": "Kristen Akin",
  "Address": {
      "city": null,
      "country": "USA",
      "state": "CA",
      "stateCode": null,
      "street": null
  },
  "Phone": "(434) 369-3100"
}

目前我正在以我能想象的最糟糕的方式接收数据,使用不同的类型,例如:

{
  "attributes": {
    "type": "Lead",
    "url": "/services/data/v30.0/sobjects/Lead/00Qi000000Jr44XEAR"
  },
  "Id": "00Qi000000Jr44XEAR",
  "Name": "Kristen Akin",
  "Address": "",
  "Phone": "(434) 369-3100"
}

我想提出更好的方法,我想知道最好的方法是什么?

  1. 完全离开地址子文档
  2. 收到“地址:空”
  3. 接收地址:{}
  4. 接收地址:{"city": null, "country": null, ...}
  5. 其他

就我个人而言,我会选择 Nr。 3 因为我仍然得到一个(子)文档并且可以按照通常的方式处理它。是否有任何反对意见或针对这种情况有任何最佳做法?

提前致谢。

此致。

我总是区分以下值:

  • 设置但为空:我们通常将这些值解释为旨在为空的有效值,就像一个空的地址簿,可能根本不包含任何条目。
  • undefined:通常这是一个可选值。应用程序必须处理是否需要来自其他地方的数据。
  • null:故意将一个值设置为null 意味着使该值无效。我们经常使用它来重置数据。通讯录的情况就是:根本没有通讯录,甚至没有空的。

我更喜欢这些选项:

1.: 如果它被遗漏,它是未定义的,意味着由应用程序处理未定义的值。特别是对于可选值,您应该注意处理未定义的值。

3.: 如果是空的,你仍然有一个有效的地址簿,但是是一个空的,这使得代码中的处理更容易。

我会避免的事情:

4.: 你得到一个有效的地址,但数据无效,所以你必须深入检查地址是否可用,这增加了验证的工作量,所以我不会使用这个选项。

5.: 将数据类型更改为 "" 也很糟糕,因为对于类型化语言来说,这将使其难以解析,因为它需要一个对象但接收到一个字符串。

选择 3。

  1. 完全省略地址子文档

适用于许多反序列化工具,但很难识别结构并在调试时轻松识别是否缺少某些内容

  1. 收到“地址:空”

适用于许多反序列化工具,但为更复杂的属性(如数组或对象)传递 null 不是一个好的做法。您无法轻易识别出这是一个复杂的对象。

  1. 接收地址:{}

如果数组是空的,传递空数组是一个很好的做法,如果它们是空的,则传递空对象。您可以确定可能有一个复杂的对象,但它在此处不可用。请使用此解决方案

  1. 接收地址:{"city": null, "country": null, ...}

不要这样做。它为您提供了有关复杂对象的更多详细信息,但如果地址不是故意添加的,或者 API 合作伙伴是否意外发送了不完整的地址数据,或者不完整的数据对他们而言是否有效,您将无法轻松识别。