Unless explicitly restricted, the JSON schema validation allows omitting and adding fields. Check the message validation against the schema in the following table:
| Schema Definition |
Message |
Valid |
{ A: integer, B: string } |
{A, B} |
Yes |
{ A: integer, B: string } |
{C, D} |
Yes |
{ A: integer, B: string } required [A, B] |
{C, D} |
No |
{ A: integer, B: string } required [A, B] |
{A, B, C} |
Yes |
{ A: integer, B: string } required [A, B] additionalProperties = false |
{A, B, C} |
No |
{ A: integer, B: string } required [A, B] additionalProperties = false |
{A, B} |
No |
The schemas must specify required and additionalProperties in the API specification.
|
|
The field value is checked against the type specified in the schema as part of the validation.
|
If an operation has multiple message schemas associated in the specification, the validation adheres to these principles:
-
Messages are validated against every schema.
-
If it’s compliant with at least one schema, the message is considered valid.
-
If the message doesn’t adhere to at least one schema, the message is considered invalid.
Example
| Schema Definition |
Message |
Valid |
{ A: integer, B: string } required [A, B] additionalProperties = false { C: integer, D: string } required [C, D] additionalProperties = false |
{A, B} |
Yes |
{ A: integer, B: string } required [A, B] additionalProperties = false { C: integer, D: string } required [C, D]
additionalProperties = false |
{B, C} |
No |
{ A: integer, B: string } required [A, B] additionalProperties = false { C: integer, D: string } required [C, D]
additionalProperties = false |
{A, B, C} |
No |
{ A: integer, B: string } required [A, B] additionalProperties = false { C: integer, D: string } required [C, D]
additionalProperties = false |
{C, D} |
Yes |