For those unfamiliar with Asyncapi we use a superset of JSON Schema as the default format for defining operation payloads, headers, channel parameter

Using JSON Schema Beyond Validation

submited by
Style Pass
2021-08-03 11:30:03

For those unfamiliar with Asyncapi we use a superset of JSON Schema as the default format for defining operation payloads, headers, channel parameter schemas, etc.

Even though formats such as Avro, OpenAPI 3.x and Swagger 2.x, RAML schemas, etc, are allowed in its place, as soon as it hits the parser (which most tooling utilizes), said formats are converted to JSON Schema draft 7 to ensure a common structure for tooling.

However, in tooling, many times you do not want to validate data, but to represent the data in a structured manner so it is easier to interact with, such as classes that represent a message payload. How can you achieve this with validation rules?

Let's try and take a look at an example. Given the following, I have defined a schema representing the validation rules that the data should comply with.

The JSON Schema defines that the JSON data should be an object, which requires a property called someRequiredProperty to always be present and an optional property called someOptionalProperty. someRequiredProperty should validate against an integer and someOptionalProperty against an arbitrary string. The schema also dictates that no additional properties ("additionalProperties": false) may be allowed. There is also some metadata defined, called $id and $schema, but they are not important for this example.

Leave a Comment