json - 如何根据 Type 对象属性的值来验证某些对象属性的存在和值?
问题描述
我正在尝试验证比下面更复杂的 JSON,但希望这个更简单的示例清楚地说明了这个问题。
在更复杂的模式中,我需要一个对象数组,其中:
- 所有对象都有一组相同的属性,例如名称和类型
- Type属性是允许的对象类型的枚举,例如“全职”、“承包商”
- 基于Type属性的值,定义了额外的每个类型的属性集。例如,“全职”员工具有必需的薪金属性和可选的电子邮件属性,而“承包商”员工具有必需的费率属性,没有可选的附加属性。
- 每个对象中只应允许定义的属性
- 每个对象的必需属性可能包括所有对象共有的属性,例如Name和Type,以及特定于一种对象类型的属性,例如Salary
这似乎应该是一个常见问题,但到目前为止,我还没有找到似乎与我正在尝试做的完全匹配的东西。这些接近了,但我无法确切地弄清楚如何将它们应用于和/或哪种方法最适合我的用例,因此希望更好地了解该领域的人可以提供帮助:
- oneOf之前是否可以有共同的属性?
- 如何根据字段描述的对象类型针对 JSON 模式验证 JSON 对象?
- 如何根据另一个属性的值设置模式对象的类型?
- JsonSchema:根据另一个属性的值验证类型
特别是,还不清楚 required 和 additionalProperties 关键字应该如何在 common 和 per-object 属性中起作用。
到目前为止我的架构,有不需要的重复:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "array",
"items": {
"$ref": "#/definitions/Employee"
},
"definitions": {
"Employee": {
"type": "object",
"oneOf": [{
"properties": {
"Name": { "type": "string" },
"Type": { "type": "string", "enum": [ "Full-Time" ] },
"Salary": { "type": "integer" },
"Email": { "type": "string" }
},
"required": [ "Name", "Type", "Salary" ],
"additionalProperties": false
},
{
"properties": {
"Name": { "type": "string" },
"Type": { "type": "string", "enum": [ "Contractor" ] },
"Rate": { "type": "number" }
},
"required": [ "Name", "Type", "Rate" ],
"additionalProperties": false
}]
}
}
}
要验证此数据:
[
{ "Name": "Good First Employee", "Type": "Full-Time", "Salary": 100000, "Email": "first.employee@example.com" },
{ "Name": "Good Second Employee", "Type": "Full-Time", "Salary": 90000 },
{ "Name": "Good First Contractor", "Type": "Contractor", "Rate": 20.00 },
{ "Name": "Good Second Contractor", "Type": "Contractor", "Rate": 25 },
{ "Name": "Bad First Person", "Type": "Unknown", "Salary": 90000 },
{ "Name": "Bad Third Employee", "Type": "Full-Time" },
{ "Name": "Bad Fourth Employee", "Type": "Full-Time", "Rate": 49.00 },
{ "Name": "Bad Fifth Employee", "Type": "Full-Time", "Salary": 100000, "Phone": "123-123-1234" },
{ "Name": "Bad Second Person" }
]
对于上述数据,名称以“Good”开头的对象是有效的。其余以“Bad”开头的都是无效的:
- 第一人称错误 - 类型无效
- 糟糕的第三名员工 - 缺少薪水
- 糟糕的第四名员工 - 缺少薪水,员工的费率无效
- 糟糕的第五名员工 - 员工的电话无效
- 错误的第二人称 - 缺少类型(常见字段)
其中一些可行,但有过多的错误消息无法清楚地指出问题所在。
解决方案
这是一个常见的问题。遗憾的是,您不需要的重复是使您想要的草稿 7 JSON 模式发生的唯一方法。
我们(JSON Schema 核心团队)在为 Draft-8 添加新关键字方面做了大量工作,但尚未发布/完成。https://github.com/json-schema-org/json-schema-spec/issues/556 - unevaluatedProperties
。
链接的问题包含很多细节,包括 OpenAPI 规范存在相同问题的示例,并因此使用了大量的重复数据删除。新的关键词减少了很多重复。
推荐阅读
- html - 处理距离其他项目类似的新项目CSS
- laravel - 如何将 Vue 组件导入脚本标签?
- java - Kali Linux 中的 Android Studio:运行按钮根本不执行任何操作
- php - 在 $_Session 中存储用户权限
- java - 带有各种分隔符的 Spark CSV 到 DataSet
- python - Python, Requests: 使用 Requests, Python 帮助在本网站上提交表单
- python - 将两个列表转换为字典错误
- c - #define 的优点而不是在嵌入式中创建函数
- wordpress - 使用管道联系表格 7 可选收件人 - 多封电子邮件
- java - Spring Batch - ORA 12516 SQLState 66000 - TNS:Listener 无法使用具有匹配协议堆栈的处理程序