JSON
Schema
Learn
Docs
ImplementationsBlog

Creating a schema

Introduction

The following example is by no means definitive of all the value JSON Schema can provide. For this you will need to go deep into the specification itself -- learn more at https://json-schema.org/specification.

Let's pretend we're interacting with a JSON based product catalog. This catalog has a product which has:

  • An identifier: productId
  • A product name: productName
  • A selling cost for the consumer: price
  • An optional set of tags: tags.

For example:

data
1
{
2
"productId": 1,
3
"productName": "A green door",
4
"price": 12.50,
5
"tags": [ "home", "green" ]
6
}

While generally straightforward, the example leaves some open questions. Here are just a few of them:

  • What is productId?
  • Is productName required?
  • Can the price be zero (0)?
  • Are all of the tags string values?

When you're talking about a data format, you want to have metadata about what keys mean, including the valid inputs for those keys. JSON Schema is a proposed IETF standard how to answer those questions for data.

Starting the schema

To start a schema definition, let's begin with a basic JSON schema.

We start with four properties called keywords which are expressed as JSON keys.

Yes. the standard uses a JSON data document to describe data documents, most often that are also JSON data documents but could be in any number of other content types like text/xml.

  • The $schema keyword states that this schema is written according to a specific draft of the standard and used for a variety of reasons, primarily version control.
  • The $id keyword defines a URI for the schema, and the base URI that other URI references within the schema are resolved against.
  • The title and description annotation keywords are descriptive only. They do not add constraints to the data being validated. The intent of the schema is stated with these two keywords.
  • The type validation keyword defines the first constraint on our JSON data and in this case it has to be a JSON Object.
schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product in the catalog",
6
"type": "object"
7
}

We introduce the following pieces of terminology when we start the schema:

Defining the properties

productId is a numeric value that uniquely identifies a product. Since this is the canonical identifier for a product, it doesn't make sense to have a product without one, so it is required.

In JSON Schema terms, we update our schema to add:

  • The properties validation keyword.
  • The productId key.
    • description schema annotation and type validation keyword is noted -- we covered both of these in the previous section.
  • The required validation keyword listing productId.
schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product from Acme's catalog",
6
"type": "object",
7
"properties": {
8
"productId": {
9
"description": "The unique identifier for a product",
10
"type": "integer"
11
}
12
},
13
"required": [ "productId" ]
14
}
  • productName is a string value that describes a product. Since there isn't much to a product without a name it also is required.
  • Since the required validation keyword is an array of strings we can note multiple keys as required; We now include productName.
  • There isn't really any difference between productId and productName -- we include both for completeness since computers typically pay attention to identifiers and humans typically pay attention to names.
schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product from Acme's catalog",
6
"type": "object",
7
"properties": {
8
"productId": {
9
"description": "The unique identifier for a product",
10
"type": "integer"
11
},
12
"productName": {
13
"description": "Name of the product",
14
"type": "string"
15
}
16
},
17
"required": [ "productId", "productName" ]
18
}

Going deeper with properties

According to the store owner there are no free products. ;)

  • The price key is added with the usual description schema annotation and type validation keywords covered previously. It is also included in the array of keys defined by the required validation keyword.
  • We specify the value of price must be something other than zero using the exclusiveMinimum validation keyword.
    • If we wanted to include zero as a valid price we would have specified the minimum validation keyword.
schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product from Acme's catalog",
6
"type": "object",
7
"properties": {
8
"productId": {
9
"description": "The unique identifier for a product",
10
"type": "integer"
11
},
12
"productName": {
13
"description": "Name of the product",
14
"type": "string"
15
},
16
"price": {
17
"description": "The price of the product",
18
"type": "number",
19
"exclusiveMinimum": 0
20
}
21
},
22
"required": [ "productId", "productName", "price" ]
23
}

Next, we come to the tags key.

The store owner has said this:

  • If there are tags there must be at least one tag,
  • All tags must be unique; no duplication within a single product.
  • All tags must be text.
  • Tags are nice but they aren't required to be present.

Therefore:

  • The tags key is added with the usual annotations and keywords.
  • This time the type validation keyword is array.
  • We introduce the items validation keyword so we can define what appears in the array. In this case: string values via the type validation keyword.
  • The minItems validation keyword is used to make sure there is at least one item in the array.
  • The uniqueItems validation keyword notes all of the items in the array must be unique relative to one another.
  • We did not add this key to the required validation keyword array because it is optional.
schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product from Acme's catalog",
6
"type": "object",
7
"properties": {
8
"productId": {
9
"description": "The unique identifier for a product",
10
"type": "integer"
11
},
12
"productName": {
13
"description": "Name of the product",
14
"type": "string"
15
},
16
"price": {
17
"description": "The price of the product",
18
"type": "number",
19
"exclusiveMinimum": 0
20
},
21
"tags": {
22
"description": "Tags for the product",
23
"type": "array",
24
"items": {
25
"type": "string"
26
},
27
"minItems": 1,
28
"uniqueItems": true
29
}
30
},
31
"required": [ "productId", "productName", "price" ]
32
}

Nesting data structures

Up until this point we've been dealing with a very flat schema -- only one level. This section demonstrates nested data structures.

  • The dimensions key is added using the concepts we've previously discovered. Since the type validation keyword is object we can use the properties validation keyword to define a nested data structure.
    • We omitted the description annotation keyword for brevity in the example. While it's usually preferable to annotate thoroughly in this case the structure and key names are fairly familiar to most developers.
  • You will note the scope of the required validation keyword is applicable to the dimensions key and not beyond.
schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product from Acme's catalog",
6
"type": "object",
7
"properties": {
8
"productId": {
9
"description": "The unique identifier for a product",
10
"type": "integer"
11
},
12
"productName": {
13
"description": "Name of the product",
14
"type": "string"
15
},
16
"price": {
17
"description": "The price of the product",
18
"type": "number",
19
"exclusiveMinimum": 0
20
},
21
"tags": {
22
"description": "Tags for the product",
23
"type": "array",
24
"items": {
25
"type": "string"
26
},
27
"minItems": 1,
28
"uniqueItems": true
29
},
30
"dimensions": {
31
"type": "object",
32
"properties": {
33
"length": {
34
"type": "number"
35
},
36
"width": {
37
"type": "number"
38
},
39
"height": {
40
"type": "number"
41
}
42
},
43
"required": [ "length", "width", "height" ]
44
}
45
},
46
"required": [ "productId", "productName", "price" ]
47
}

References outside the schema

So far our JSON schema has been wholly self contained. It is very common to share JSON schema across many data structures for reuse, readability and maintainability among other reasons.

For this example we introduce a new JSON Schema resource and for both properties therein:

  • We use the minimum validation keyword noted earlier.
  • We add the maximum validation keyword.
  • Combined, these give us a range to use in validation.
schema
1
{
2
"$id": "https://example.com/geographical-location.schema.json",
3
"$schema": "https://json-schema.org/draft/2020-12/schema",
4
"title": "Longitude and Latitude",
5
"description": "A geographical coordinate on a planet (most commonly Earth).",
6
"required": [ "latitude", "longitude" ],
7
"type": "object",
8
"properties": {
9
"latitude": {
10
"type": "number",
11
"minimum": -90,
12
"maximum": 90
13
},
14
"longitude": {
15
"type": "number",
16
"minimum": -180,
17
"maximum": 180
18
}
19
}
20
}

Next we add a reference to this new schema so it can be incorporated.

schema
1
{
2
"$schema": "https://json-schema.org/draft/2020-12/schema",
3
"$id": "https://example.com/product.schema.json",
4
"title": "Product",
5
"description": "A product from Acme's catalog",
6
"type": "object",
7
"properties": {
8
"productId": {
9
"description": "The unique identifier for a product",
10
"type": "integer"
11
},
12
"productName": {
13
"description": "Name of the product",
14
"type": "string"
15
},
16
"price": {
17
"description": "The price of the product",
18
"type": "number",
19
"exclusiveMinimum": 0
20
},
21
"tags": {
22
"description": "Tags for the product",
23
"type": "array",
24
"items": {
25
"type": "string"
26
},
27
"minItems": 1,
28
"uniqueItems": true
29
},
30
"dimensions": {
31
"type": "object",
32
"properties": {
33
"length": {
34
"type": "number"
35
},
36
"width": {
37
"type": "number"
38
},
39
"height": {
40
"type": "number"
41
}
42
},
43
"required": [ "length", "width", "height" ]
44
},
45
"warehouseLocation": {
46
"description": "Coordinates of the warehouse where the product is located.",
47
"$ref": "https://example.com/geographical-location.schema.json"
48
}
49
},
50
"required": [ "productId", "productName", "price" ]
51
}

Taking a look at data for our defined JSON Schema

We've certainly expanded on the concept of a product since our earliest sample data (scroll up to the top). Let's take a look at data which matches the JSON Schema we have defined.

data
1

2
{
3
"productId": 1,
4
"productName": "An ice sculpture",
5
"price": 12.50,
6
"tags": [ "cold", "ice" ],
7
"dimensions": {
8
"length": 7.0,
9
"width": 12.0,
10
"height": 9.5
11
},
12
"warehouseLocation": {
13
"latitude": -78.75,
14
"longitude": 20.4
15
}
16
}