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"
}
我想提出更好的方法,我想知道最好的方法是什么?
- 完全离开地址子文档
- 收到“地址:空”
- 接收地址:{}
- 接收地址:{"city": null, "country": null, ...}
- 其他
就我个人而言,我会选择 Nr。 3 因为我仍然得到一个(子)文档并且可以按照通常的方式处理它。是否有任何反对意见或针对这种情况有任何最佳做法?
提前致谢。
此致。
我总是区分以下值:
- 设置但为空:我们通常将这些值解释为旨在为空的有效值,就像一个空的地址簿,可能根本不包含任何条目。
- undefined:通常这是一个可选值。应用程序必须处理是否需要来自其他地方的数据。
- null:故意将一个值设置为null 意味着使该值无效。我们经常使用它来重置数据。通讯录的情况就是:根本没有通讯录,甚至没有空的。
我更喜欢这些选项:
1.: 如果它被遗漏,它是未定义的,意味着由应用程序处理未定义的值。特别是对于可选值,您应该注意处理未定义的值。
3.: 如果是空的,你仍然有一个有效的地址簿,但是是一个空的,这使得代码中的处理更容易。
我会避免的事情:
4.: 你得到一个有效的地址,但数据无效,所以你必须深入检查地址是否可用,这增加了验证的工作量,所以我不会使用这个选项。
5.: 将数据类型更改为 "" 也很糟糕,因为对于类型化语言来说,这将使其难以解析,因为它需要一个对象但接收到一个字符串。
选择 3。
- 完全省略地址子文档
适用于许多反序列化工具,但很难识别结构并在调试时轻松识别是否缺少某些内容
- 收到“地址:空”
适用于许多反序列化工具,但为更复杂的属性(如数组或对象)传递 null 不是一个好的做法。您无法轻易识别出这是一个复杂的对象。
- 接收地址:{}
如果数组是空的,传递空数组是一个很好的做法,如果它们是空的,则传递空对象。您可以确定可能有一个复杂的对象,但它在此处不可用。请使用此解决方案
- 接收地址:{"city": null, "country": null, ...}
不要这样做。它为您提供了有关复杂对象的更多详细信息,但如果地址不是故意添加的,或者 API 合作伙伴是否意外发送了不完整的地址数据,或者不完整的数据对他们而言是否有效,您将无法轻松识别。
我从一个包含几个嵌套子文档的应用程序中得到 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"
}
我想提出更好的方法,我想知道最好的方法是什么?
- 完全离开地址子文档
- 收到“地址:空”
- 接收地址:{}
- 接收地址:{"city": null, "country": null, ...}
- 其他
就我个人而言,我会选择 Nr。 3 因为我仍然得到一个(子)文档并且可以按照通常的方式处理它。是否有任何反对意见或针对这种情况有任何最佳做法?
提前致谢。
此致。
我总是区分以下值:
- 设置但为空:我们通常将这些值解释为旨在为空的有效值,就像一个空的地址簿,可能根本不包含任何条目。
- undefined:通常这是一个可选值。应用程序必须处理是否需要来自其他地方的数据。
- null:故意将一个值设置为null 意味着使该值无效。我们经常使用它来重置数据。通讯录的情况就是:根本没有通讯录,甚至没有空的。
我更喜欢这些选项:
1.: 如果它被遗漏,它是未定义的,意味着由应用程序处理未定义的值。特别是对于可选值,您应该注意处理未定义的值。
3.: 如果是空的,你仍然有一个有效的地址簿,但是是一个空的,这使得代码中的处理更容易。
我会避免的事情:
4.: 你得到一个有效的地址,但数据无效,所以你必须深入检查地址是否可用,这增加了验证的工作量,所以我不会使用这个选项。
5.: 将数据类型更改为 "" 也很糟糕,因为对于类型化语言来说,这将使其难以解析,因为它需要一个对象但接收到一个字符串。
选择 3。
- 完全省略地址子文档
适用于许多反序列化工具,但很难识别结构并在调试时轻松识别是否缺少某些内容
- 收到“地址:空”
适用于许多反序列化工具,但为更复杂的属性(如数组或对象)传递 null 不是一个好的做法。您无法轻易识别出这是一个复杂的对象。
- 接收地址:{}
如果数组是空的,传递空数组是一个很好的做法,如果它们是空的,则传递空对象。您可以确定可能有一个复杂的对象,但它在此处不可用。请使用此解决方案
- 接收地址:{"city": null, "country": null, ...}
不要这样做。它为您提供了有关复杂对象的更多详细信息,但如果地址不是故意添加的,或者 API 合作伙伴是否意外发送了不完整的地址数据,或者不完整的数据对他们而言是否有效,您将无法轻松识别。