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.
|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
This assertion is available in multiple ReadyAPI applications. Depending on the application, it validates the following data:
|In...||Checks...||To learn more...|
|Functional tests||The request or response body.||See Working With Assertions in Functional Tests.|
|Security tests||The response body.||See Security Assertions.|
|Virtual services||The request body.||See Assertions in Virtual Services.|
Create an assertion
Setting up properties
Specify the definition URL in the field.
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:
Other schema compliance assertions
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.
Compliance, Status and Standards Assertions
JSON Schema Compliance Assertions