Някои въпроси, свързани с персонализирана json схема

Аз съм нуб на json. Докато определях формата на резултата на моя RESTful API (а именно JSON), почувствах, че ще бъде по-лесно да го документирам като моя собствена JSON схема. Докато пишех един, имах няколко въпроса:

  1. В моя резултат JSON, как да посоча URI към схемата, към която се потвърждава? --edit-- използва ли атрибут $schema?
  2. Има ли някакви конвенции/насоки за версия на JSON схема? Има ли някои атрибути, които трябва/мога да дефинирам в моята схема като атрибути? Виждам, че самата JSON схема няма дефинирана версия, освен в нейния URI, посочен като стойност на ключ $schema.
  3. Мога ли да разделя моята една BIG JSON схема на множество по-малки и да включа една в друга? Като #include в C++, след това се обърнете към множество схеми в JSON, който изпратих на потребителя като резултат.
  4. Мога ли да дефинирам персонализирана стойност за ключ "type"? напр. Бих искал да използвам отново дефиницията на "дата" по този начин:

[игнорирайте този ред, той е, за да накарате форматирането да работи за следване на 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 в спецификацията, това е не е възможно, но изглежда като такъв основен случай на употреба!


json jsonschema
person Kashyap    schedule 20.11.2011    source източник

Отговори (4)


arrow_upward
4
arrow_downward

  1. Както правилно разбрахте, $schema може да се използва за указване на схемата, на която съответства.
  2. Всъщност намерих тази тема, докато търсих в Google за версия на JSON Schema и идеята за използване на URI за версия на версия звучи логично.
  3. Можете да използвате $ref за свързване към друга схема, която след това се изтегля.
  4. Отново можете да използвате $ref и JSON указател за импортиране на дефиниции от други схеми.

Винаги можете да тествате нещата, като потвърдите схемата си, за да видите дали сте направили всякакви грешки.

person Miha Hribar    schedule 17.09.2013

arrow_upward
3
arrow_downward

Към момента на писане на тази статия текущата версия на спецификацията на JSON Schema е draft-v4, в която форматът date-time за string екземпляри е ясно указано и е много полезно на практика.

Досега няма дефиниран по-прост формат date, но можете лесно да дефинирате свойството на вашия обект като тип string и след това да приложите format проверка на шаблон (ECMA 262 regex диалект) отгоре.

Например:

{
    "$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
Но какво ще стане, ако той има birth_date и death_date и join_date и last_modified_date и т.н... какво тогава, дублиране на шаблона навсякъде? - person Joshua Cheek; 27.05.2017

arrow_upward
2
arrow_downward

Защо просто не използвате "format" : "date" според #5.23 в JSON Schema Draft 03?

Освен това вашата дефиниция за дата на раждане не съдържа дата, което изглежда е грешка.

person Artem Oboturov    schedule 26.07.2012
comment
Благодаря. Въпросът беше по-скоро да се разбере как да се дефинират персонализирани структури, отколкото как да се дефинира „дата“, което беше предназначено само като пример. - person Kashyap; 17.09.2013
comment
@artemoboturov Връзката към #5.23 е валидна за JSON Schema Draft 3, но в последната стабилна чернова 04 не присъства. Документът за валидиране на JSON схема в раздел 7.3.1 декларира формат с вальор-час. За съжаление няма дата. - person Jan Vlcinsky; 30.06.2014

arrow_upward
1
arrow_downward

Спецификацията изглежда предполага, че бихте могли:

Други стойности на типа МОГАТ да се използват за потребителски цели,...

След това се обсъжда какво могат да направят валидаторите на минималната реализация.

Според мен това, което искаш да направиш, изглежда добре. Може да помогне за яснотата на вашата схема да запазите препратката към типа и дефиницията на типа в един и същ файл.

Мисля, че вашият файл включва 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