Некоторые вопросы, связанные с пользовательской схемой json

Я нуб в json. Определяя формат результата моего RESTful API (а именно JSON), я чувствовал, что будет проще документировать его как мою собственную схему схема JSON. При написании у меня возникло несколько вопросов:

  1. В моем результате JSON, как мне указать URI для схемы, которую он подтверждает? --edit-- используется атрибут $schema?
  2. Существуют ли какие-либо соглашения/рекомендации по управлению версиями схемы JSON? Есть ли какие-то атрибуты, которые я должен/могу определить в своей схеме как атрибуты? Я вижу, что сама схема JSON не имеет определенной версии, кроме как в ее URI, указанном как значение ключа $schema.
  3. Могу ли я разбить одну БОЛЬШУЮ схему JSON на несколько меньших и включить одну в другую? Подобно #include в C++, затем ссылайтесь на несколько схем в JSON, который я отправил пользователю в качестве результата.
  4. Могу ли я определить пользовательское значение для ключа «тип»? Например. Я хотел бы повторно использовать определение «дата» следующим образом:

[игнорируйте эту строку, это нужно для того, чтобы форматирование работало для следующего json..]

{
    "date":{
        "type":"object",
        "properties":{
            "month":{
                "type":"integer",
                "minimum":1,
                "maximum":12
            },
            "year":{
                "type":"integer",
                "minimum":0
            }
        }
    },
    "personInfo":{
        "type":"object",
        "properties":{
            "name":{
                "type":"string"
            },
            "dateOfBirth":{
                "type":"date"
            }
        }
    },
    "student":{
        "type":"object",
        "properties":{
            "id":{
                "type":"personInfo"
            },
            "pass_out_year":{
                "type":"date"
            }
        }
    }
}

вместо предоставления свойств «даты» в нескольких местах, например:

{
    "personInfo":{
        "type":"object",
        "properties":{
            "name":{
                "type":"string"
            },
            "dateOfBirth":{
                "type":"object",
                "properties":{
                    "month":{
                        "type":"integer",
                        "minimum":1,
                        "maximum":12
                    },
                    "year":{
                        "type":"integer",
                        "minimum":0
                    }
                }
            }
        }
    },
    "student":{
        "type":"object",
        "properties":{
            "id":{
                "type":"personInfo"
            },
            "pass_out_year":{
                "type":"object",
                "properties":{
                    "month":{
                        "type":"integer",
                        "minimum":1,
                        "maximum":12
                    },
                    "year":{
                        "type":"integer",
                        "minimum":0
                    }
                }
            }
        }
    }
}

согласно 5.1 введите в спецификации, это невозможно, но это похоже на такой простой вариант использования!


person Kashyap    schedule 20.11.2011    source источник


Ответы (4)


  1. Как вы правильно поняли, $schema можно использовать для указания схемы, которой он соответствует.
  2. На самом деле я нашел эту тему, когда искал версию JSON Schema, и идея использования URI для версии звучит логично.
  3. Вы можете использовать $ref для ссылки на другую схему, которая затем загружается.
  4. Опять же, вы можете использовать $ref и указатель JSON для импорта определений из других схем.

Вы всегда можете все проверить, проверив свою схему, чтобы увидеть, сделали ли вы любые ошибки.

person Miha Hribar    schedule 17.09.2013

На момент написания этой статьи текущая версия спецификации схемы JSON — draft-v4, в которой формат date-time для string экземпляров — четко указан и очень полезен на практике.

Пока еще не определен более простой формат date, но вы можете легко определить свойство вашего объекта как тип string, а затем применить format проверка шаблона (диалект регулярных выражений ECMA 262) поверх него.

Например:

{
    "$schema": "http://json-schema.org/draft-04/schema",
    "title": "Example Schema"
    "description": "This schema contains only a birth date property"
    "type": "object",
    "required": ["birth_date"],
    "properties": {
        "birth_date": {
            "type": "string",
            "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}$"
        }
    }
}
person jose.angel.jimenez    schedule 23.05.2014
comment
А если у него есть и рождения_дата и смерти_дата и присоединения_дата и последняя_измененная_дата и т.д... что тогда, везде дублировать паттерн? - person Joshua Cheek; 27.05.2017

Почему бы вам просто не использовать "format" : "date" согласно #5.23? в проекте схемы JSON 03?

Кроме того, ваше определение даты рождения не содержит даты, что кажется ошибкой.

person Artem Oboturov    schedule 26.07.2012
comment
Спасибо. Вопрос был больше в том, чтобы понять, как определить пользовательские структуры, а не как определить «дату», что было задумано только как пример. - person Kashyap; 17.09.2013
comment
@artemoboturov Ссылка на № 5.23 действительна для черновика схемы JSON 3, но в последнем стабильном черновике 04 ее нет. Документ проверки схемы JSON в разделе 7.3.1 объявляет формат с значение даты-времени. К сожалению даты нет. - person Jan Vlcinsky; 30.06.2014

Спецификация, кажется, предполагает, что вы можете:

Значения других типов МОГУТ использоваться для пользовательских целей,...

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

На мой взгляд, то, что вы хотите сделать, выглядит нормально. Сохранение ссылки на тип и определение типа в одном файле может помочь ясности вашей схемы.

Я думаю, что ваш файл включает в себя Q, который должен обрабатываться вне json, например. есть шаг разработки, который генерирует полный json из сценария/шаблона (например, erb или что-то подобное), объединяя ваши подфайлы. На мой взгляд, ваша служба всегда должна предоставлять полный json, необходимый для полного взаимодействия с этой службой. Если это становится неуправляемым с точки зрения клиентов, это может быть сигналом к ​​рефакторингу и внедрению другого сервиса.

person Hedgehog    schedule 26.06.2012
comment
Кажется, слишком много работы, поэтому я не буду этого делать. Но да, это осуществимый вариант, особенно в сегодняшней технологической среде. Я уверен, что найду инструменты для этого на любом языке/среде. Спасибо. - person Kashyap; 17.09.2013
comment
В v4 схемы JSON это больше не разрешено: json-schema .org/latest/json-schema-validation.html#anchor79 - person Mitar; 30.05.2015