Я пытаюсь проверить JSON, который является более сложным, чем то, что ниже, но, надеюсь, этот более простой пример ясно иллюстрирует проблему.
В более сложной схеме мне нужно иметь массив объектов, где:
- Все объекты имеют набор одинаковых свойств, например Имя и Тип
- Свойство Тип является списком разрешенных типов объектов, таких как «Полный рабочий день», «Подрядчик»
- На основе значения свойства Type определяется дополнительный набор свойств для каждого типа. Например, у сотрудника с полной занятостью есть обязательное свойство Зарплата и необязательное свойство Email , а у сотрудника "Подрядчик" Коэффициент свойство, которое является обязательным, и необязательные дополнительные свойства.
- В каждом объекте должны быть разрешены только те свойства, которые определены
- Обязательные свойства для каждого объекта могут включать свойства, общие для всех объектов, такие как Имя и Тип , а также свойства, характерные для одного типа объекта, такие как Зарплата
Кажется, это должно быть обычной проблемой, но до сих пор я не смог найти что-то, что, кажется, точно соответствует тому, что я пытаюсь сделать. Они подошли близко, но я не мог точно определить, как их применять и / или какой метод лучше всего подходит для моего варианта использования, поэтому надеюсь, что кто-то, кто понимает эту область лучше, может помочь:
В частности, неясно, как обязательные и дополнительные ключевые словаProperties должны работать с общими свойствами для каждого объекта.
Схема, которая у меня пока есть, с нежелательным дублированием:
{
"$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" }
]
Для приведенных выше данных допустимы объекты с Name , начинающимися с "Good". Остальные, начинающиеся с «Плохо», недействительны:
- Bad First Person - неверный тип
- Плохой третий сотрудник - отсутствует зарплата
- Плохой четвертый сотрудник - отсутствует зарплата, ставка недействительна для сотрудника
- Плохой Пятый Сотрудник - Телефон недействителен для Сотрудника
- Плохой второй человек - пропущенный тип (общее поле)
Часть этого работает, но с чрезмерными сообщениями об ошибках, которые не ясно указывают, где проблема.