CODEWITHSUNDEEP
jsonschema
KeithSmith
KeithSmith

Reputation: 774

Use of type : object and properties in JSON schema

I'm new to JSON.

I see in various examples of JSON, like the following, where complex values are prefixed with "type":"object", properties { }

{
 "$schema": "http://json-schema.org/draft-06/schema#",
 "motor" : { 
  "type" : "object",
  "properties" : {
    "class" : "string",
    "voltage" : "number",
    "amperage" : "number"
  }
 }
}

I have written JSON without type, object, and properties, like the following.

{
 "$schema": "http://json-schema.org/draft-06/schema#",
 "motor" : { 
    "class" : "string",
    "voltage" : "number",
    "amperage" : "number"
 }
}

and submitted to an on-line JSON schema validator with no errors.

What is the purpose of type:object, properties { }? Is it optional?

Upvotes: 0

Views: 515

Answers (1)

mdo123
mdo123

Reputation: 1897

Yes it is optional, try removing it and use your validator. 

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "foo": "bar"
}

You actually don't even need to use the $schema keyword i.e. {} is valid json

I would start by understanding what json is, https://www.json.org/ is the best place to start but you may prefer something easier to read like https://www.w3schools.com/js/js_json_intro.asp.

A schema is just a template (or definition) to make sure you're producing valid json for the consumer

As an example let's say you have an application that parses some json and looks for a key named test_score and saves the value (the score) in a database in some table/column. For this example we'll call the table tests and the column score. Since a database column requires a type we'll choose a numeric type, i.e. integer for our score column.

A valid json example for this may look like

{
 "test_score": 100
}

Following this example the application would parse the key test_score and save the value 100 to the tests.score database table/column.

But let's say a score is absent so you put in a string i.e "NA"

{
 "test_score": "NA"
}

When the application attempts to save NA to the database it will error because NA is a string not an integer which the database expects.

If you put each of those examples into any online json validator they are valid json example. However, while it's valid json to use "NA" or 100 it is not valid for the actual application that needs to consume the json.

So now you may understand that the author of the json may wonder

What are the different valid types I can use as values for my test score?

The responsibility then falls on the writers of the application to provide some sort of definition (i.e a schema) that the clients (authors) can reference so the author knows exactly how to structure the json so the application can process it accordingly. Having a schema also allows you to validate/test your json so you know it can be processed by the application without actually having to send your json through the application.

So putting it altogether let's say in the schema you see

"$test_score": {
    "type": "integer",
    "format": "tinyint"
},

The writer of the json now knows that they must pass an integer and the range is 0 to 255 because it's a tinyint. They no longer have to trial by error different values and see which ones the application process. This is a big benefit to having a schema.

Upvotes: 1

Related Questions