Geek Answers Handbook

Some questions related to custom json schema

I am noob for json. Having defined the format of my RESTful API result (namely JSON), I felt that it would be easier to document it as my own JSON schema . At the time of writing one, I had several questions:

  • In my JSON result, how can I point the URI to the schema that it validates? --edit - does the attribute use $schema?
  • Are there any JSON schema versioning conventions / guidelines? Are there some attributes that I / should define inside my schema as attributes? I see the JSON scheme itself does not have a specific version, except that in it the URI is indicated as the key value $schema.
  • Can I split my one BIG JSON scheme into several smaller ones and include one in the other? Like #include in C ++, refer to several schemes in JSON that I sent to the user as the result.
  • Can I define a custom value for the "type" key? For instance. I would like to reuse the definition of "date" as follows:

[ignore this line to get formatting working for next 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"
            }
        }
    }
}

instead of providing the "date" properties in several places, such as:

{
    "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
                    }
                }
            }
        }
    }
}

according to type 5.1 in the specification , this is not possible, but it seems like such a basic utility!

+5
source share
4 answers
  • , $schema , .
  • JSON Schema, URI .
  • $ref , .
  • , $ref JSON Pointer .

, , - .

+4

JSON draft-v4, string date-time .

date, string, format ( regex 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}$"
        }
    }
}
+3

"format" : "date" # 5.23 JSON Draft 03?

, , .

+2

, , :

,...

, .

, , , . .

I think your file includes Q, should be processed outside of json, for example. have a dev step that generates full json from script / template (e.g. erb or some of those), combining your subfiles. In my opinion, your service should always provide the full json necessary to fully interact with this service. If it becomes unmanageable from the point of view of customers, it may be a signal for the reorganization and introduction of another service.

+1
source

More articles:


All Articles