Схема JSON описывается значениями в общей модели вместо имен, определенных в схеме

#json

#json

Вопрос:

Я рекомендую своему клиенту использовать упрощенную схему данных, в которой основной документ, которым обмениваются стороны через api, содержит статическую обязательную информацию , полученную с identifiers помощью, references , parties , dates и т.д., А затем содержит гибкие объекты в массиве, которые могут захватывать любое значение данных, которое имеет метаданные на основе таксономии для описания значения.

Альтернативный метод, который рассматривает мой клиент, сводит меня с ума. Они рассматривают возможность внесения каждого фрагмента собранных данных в схему с именем значения с самоописанием.

Мы говорим о страховой компании — по видам страхования ответственности и имущества между ними существует более 300 вопросов. Если бы это была электронная таблица, то там было бы много столбцов. Если бы клиент запрашивал только свойство, то было бы использовано только 175 из этих вопросов, а остальные являются необязательными или нулевыми значениями.

То, что я предлагаю, — это пример документа, полученного от брокера:

 {  "characteristics" [  {  "category" : "business-activities",  "type" : "activities-hot-work",  "value" : "true"  },  {  "category" : "business-employees",  "type" : "employees-full-time",  "value" : "6"  }  ] }  

Кроме того, мы могли бы иметь другую версию этого документа, хранящуюся на уровне API, которая использует те же категории и типы, но имеет правила проверки полученных значений.

Пример версии проверки полезной нагрузки:

 {  "characteristics" [  {  "category" : "business-activities",  "type" : "activities-hot-work",  "validation" : [  "value_type" : "boolean", "mandatory" : true  ]  },  {  "category" : "business-employees",  "type" : "employees-full-time",  "validation" : [  "value_type" : "integer", "mandatory" : true  ]  }  ] }  

Я бы надеялся, что, используя эти два документа, проверка соответствия значений правилам проверки должна быть довольно простой.

Имеет ли смысл моя логика? Я хочу, чтобы расширение допустимых значений для получения стало упражнением по управлению данными, а не новой схемой, которую должны обновить все производители и потребители полезной нагрузки.

Кроме того, я хочу получать только те данные, которые мне нужны для моего запроса. Я хочу, чтобы схема была легкой и гибкой. Я считаю, что схема не обязательно должна быть плоской версией страхового продукта и всевозможной комбинацией вопросов.

Я благодарен вам за совет !

Комментарии:

1. Для меня это имеет смысл.

2. @ObsidianAge есть ли что-нибудь, что я мог бы сделать лучше, или это хорошие голые кости?