The Schema Compliance assertions check whether the last request or response follows the associated WSDL or WADL schema definition. This schema can be taken from the service definition, or inferred.
Important
If the schema contains a definition of one type, and the response returns another type, the Schema Compliance assertion will always be Valid. For example, this happens if you have defined the ArrayOfInt element, but the method returns ArrayOfString.
This assertion is available in multiple ReadyAPI applications. Depending on the application, it validates the following data:
In... | Checks... | To learn more... |
|---|---|---|
The request or response body. | ||
The response body. | See Security Assertions. | |
The request body. |
Specify the definition URL in the field.
Important
By default, ReadyAPI uses the service definition that you specified in the project to verify the schema. If you have an inferred schema, ReadyAPI will use it instead.
For the REST Request test step, you can use only the inferred schema.
In functional tests, if the response you receive has conflicts with a schema, the assertion fails. These conflicts appear on the Conflicts tab of the Schema panel in the response editor. You can then resolve conflicts on that tab – either manually or automatically.
For more information on schemas in ReadyAPI, see Inferring REST Schemas.
If you receive the
Missing matching representation for response with contentTypeerror, add a new representation for the expected content type on the Representations panel:
Add other schema compliance assertions:
JSON Schema Compliance Assertion – Verifies that the JSON body of the response complies with a JSON schema.
Swagger Compliance Assertion – Verifies that the response complies with a Swagger/OpenAPI definition.