9.7 KiB
Schema Validation
jsonschema
The Basics
The simplest way to validate an instance under a given schema is to
use the validate
function.
validate
The Validator Interface
jsonschema
defines
an (informal) interface that all validator classes should adhere to.
- argument dict schema
-
the schema that the validator object will validate with. It is assumed to be valid, and providing an invalid schema can lead to undefined behavior. See
IValidator.check_schema
to validate a schema first. - argument types
-
Override or extend the list of known types when validating the
type
property. Should map strings (type names) to class objects that will be checked viaisinstance
. Seevalidating-types
for details. - type types
-
dict or iterable of 2-tuples
- argument resolver
-
an instance of
RefResolver
that will be used to resolve$ref
properties (JSON references). If unprovided, one will be created. - argument format_checker
-
an instance of
FormatChecker
whose~conforms
method will be called to check and see if instances conform to eachformat
property present in the schema. If unprovided, no validation will be done forformat
.
DEFAULT_TYPES
The default mapping of JSON types to Python types used when
validating type
properties in JSON schemas.
META_SCHEMA
An object representing the validator's meta schema (the schema that describes valid schemas in the given version).
VALIDATORS
A mapping of validator names (str
s) to functions that validate the validator
property with that name. For more information see creating-validators
.
schema
The schema that was passed in when initializing the object.
check_schema(schema)
Validate the given schema against the validator's META_SCHEMA
.
- raises
-
SchemaError
if the schema is invalid
is_type(instance, type)
Check if the instance is of the given (JSON Schema) type.
- type type
-
str
- rtype
-
bool
- raises
-
UnknownType
iftype
is not a known type.
is_valid(instance)
Check if the instance is valid under the current schema
.
- rtype
-
bool
>>> schema = {"maxItems" : 2} >>> Draft3Validator(schema).is_valid([2, 3, 4]) False
iter_errors(instance)
Lazily yield each of the validation errors in the given instance.
- rtype
-
an iterable of
ValidationError
s
>>> schema = { ... "type" : "array", ... "items" : {"enum" : [1, 2, 3]}, ... "maxItems" : 2, ... } >>> v = Draft3Validator(schema) >>> for error in sorted(v.iter_errors([2, 3, 4]), key=str): ... print(error.message) 4 is not one of [1, 2, 3] [2, 3, 4] is too long
validate(instance)
Check if the instance is valid under the current schema
.
- raises
-
ValidationError
if the instance is invalid
>>> schema = {"maxItems" : 2} >>> Draft3Validator(schema).validate([2, 3, 4]) Traceback (most recent call last): ... ValidationError: [2, 3, 4] is too long
All of the versioned validators <versioned-validators>
that
are included with jsonschema
adhere to the interface, and implementors
of validator classes that extend or complement the ones included should
adhere to it as well. For more information see creating-validators
.
Validating With Additional Types
Occasionally it can be useful to provide additional or alternate
types when validating the JSON Schema's type
property. Validators allow this by taking a
types
argument on construction that specifies additional
types, or which can be used to specify a different set of Python types
to map to a given JSON type.
jsonschema
tries to
strike a balance between performance in the common case and generality.
For instance, JSON Schema defines a number
type, which can
be validated with a schema such as {"type" : "number"}
. By
default, this will accept instances of Python numbers.Number
. This
includes in particular int
s and float
s, along with decimal.Decimal
objects, complex
numbers etc. For
integer
and object
, however, rather than
checking for numbers.Integral
and collections.abc.Mapping
, jsonschema
simply checks for
int
and dict
, since the more
general instance checks can introduce significant slowdown, especially
given how common validating these types are.
If you do want the generality, or just want to add a few
specific additional types as being acceptible for a validator object,
IValidator
s have a
types
argument that can be used to provide additional or
new types.
class MyInteger(object):
...
Draft3Validator(={"type" : "number"},
schema={"number" : (numbers.Number, MyInteger)},
types )
The list of default Python types for each JSON type is available on
each validator object in the IValidator.DEFAULT_TYPES
attribute. Note that you
need to specify all types to match if you override one of the existing
JSON types, so you may want to access the set of default types when
specifying your additional type.
Versioned Validators
jsonschema
ships
with validator classes for various versions of the JSON Schema
specification. For details on the methods and attributes that each
validator class provides see the IValidator
interface, which each included validator
class implements.
Draft3Validator
Draft4Validator
For example, if you wanted to validate a schema you created against the Draft 4 meta-schema, you could use:
from jsonschema import Draft4Validator
= {
schema "$schema": "http://json-schema.org/schema#",
"type": "object",
"properties": {
"name": {"type": "string"},
"email": {"type": "string"},
},"required": ["email"]
} Draft4Validator.check_schema(schema)
Validating Formats
JSON Schema defines the format
property which can be used to check if
primitive types (string
s, number
s,
boolean
s) conform to well-defined formats. By default, no
validation is enforced, but optionally, validation can be enabled by
hooking in a format-checking object into an IValidator
.
>>> validate("localhost", {"format" : "hostname"}) >>> validate( ... "-12", {"format" : "hostname"}, format_checker=FormatChecker(), ... ) Traceback (most recent call last): ... ValidationError: "-12" is not a "hostname"
FormatChecker
checkers
A mapping of currently known formats to tuple of functions that
validate them and errors that should be caught. New checkers can be
added and removed either per-instance or globally for all checkers using
the FormatChecker.checks
or FormatChecker.cls_checks
decorators respectively.
cls_checks(format, raises=())
Register a decorated function as globally validating a new format.
Any instance created after this function is called will pick up the supplied checker.
- argument str format
-
the format that the decorated function will check
- argument Exception raises
-
the exception(s) raised by the decorated function when an invalid instance is found. The exception object will be accessible as the
ValidationError.cause
attribute of the resulting validation error.
There are a number of default checkers that FormatChecker
s know how to
validate. Their names can be viewed by inspecting the FormatChecker.checkers
attribute. Certain checkers will only be available if an appropriate
package is available for use. The available checkers, along with their
requirement (if any,) are listed below.
Checker | Notes |
---|---|
hostname ipv4 |
|
ipv6 email |
OS must have |
uri | requires rfc3987 |
date-time date time regex |
requires strict-rfc33391 |
color | requires webcolors |
For information on creating JSON schemas to validate your data, there is a good introduction to JSON Schema fundamentals underway at Understanding JSON Schema↩︎