Validate Responses

In this section, you will learn how to validate the API responses after sending requests.

Specifying Validation Scope

1. Scope for Validate Response:

• HTTP status code returned by the API
• Data format of the returned content: JSON, XML, HTML, Raw, Binary, MsgPack, Event-Stream
• Schemas: Only JSON and XML can configure schemas. For detailed explanation of data structure, please refer Schemas.

1. If the above points are consistent, it will display "Response Data Sructure validated!". This means that the actual API return values are consistent with the API documentation specification, eliminating the need for manual verification and improving the efficiency.

3. When they are inconsistent, an error will be reported and the specific inconsistent part will be indicated. At this point, you can choose to modify the Return Response in the Edit Documentation section of the API Documentation.

The Validate Response feature can help developers verify whether the API response meets expectations. If the response defined in the API documentation is inconsistent with the actual response returned by the API, a prompt will be given to the developer to make modifications after sending the requests.

Validate Additional Fields

As the actual business upgrades, additional fields may be added to the return response. In such cases, Apidog allows users to decide on the response validation mechanism and determine whether to allow additional fields.

For example, there is currently an API for querying user information, and the previous return fields were name and phone. Therefore, the following data structure was defined in the API documentation:

With the business upgrade, a new city field was added to this API, but the API documentation was not updated. According to default validation mechanism, no error will be reported during response validation in this case, meaning that adding additional fields is allowed by default.

However, for more strict development scenarios, if the return value contains additional fields that do not match the definition, the response validation mechanism should also report an error. In this case, you can achieve the desired behavior by following these steps:

1. Modify the response in the API documentation. In the advanced settings of the object, configure "additionalProperties" to "Deny", which will only take effect for the current API.

2. If you want to disallow additional fields for all API in the project, you can go to "Settings" → "Response Validate Settings" and turn off "Allow Objects to Have additionalProperties".

3. After completing the configuration, when sending the request again, the response validation mechanism will report an error, indicating that additionalProperties are not allowed.

Module Feature Switch

The "Validate Response" switch is turned on by default, and you can adjust it in the "Verification Response Settings" in the project settings interface. This setting only takes effect for all APIs in the current project and does not affect the saved "API Cases".

If the return response is defined in the API specification in advance, Apidog's "Validate Response" function will check whether the actual returned response is consistent with the definition in the API specification, and test engineers no longer need to write assertions manually.

However, if the test engineer only focuses on the accessibility of the API, or only needs to execute manual assertions or post-scripts, and does not want Apidog to check whether the actual response is consistent with the API specification, then the validation response function of different modules can also be turned off as needed.

After turning off the validation response in the settings, manual assertions and post-scripts will still work normally.

Validate Reponse Content

The validate response contains "HTTP Status", "Header", "Body", you can adjust it in the "Validate Reponse Content" in the project settings. This setting only takes effect for all API in the current project and does not affect the saved "API Cases".