How to Establish and Validate API Response Data
To test whether the data structure returned by an interface is standardized, you can use the API documentation module of Apidog.
During the development process, it is important to standardize the response data of interfaces. With relevant interface specifications, even if problems arise during subsequent iterations, developers and testers can quickly identify the cause of the problem.
To test whether the data structure returned by an interface is standardized, you can use the API documentation module of Apidog. First, common data structures will be introduced, followed by an example to experience the design of data structures.
Example
1. Problem
Supposed there is a scenario where an object has two properties:
type: enum
values: array
When the type value is fixed, the length of values should be 1; when the type value is range, the length of values should be 2; when the type value is other, there is no limit to the length of values.
In this scenario, how can we limit the length of values based on the type value in Apidog? So that an error response can be returned if the relationship between type and values cannot be matched?
First, list all possible data structure specifications based on the requirements:
// Type A
{
"type": "fixed",
"values": ["1"]
}
// Type B
{
"type": "range",
"values": ["1","2"]
}
// Type C
{
"type": "other",
"values": ["1","2","89","67"]
}
2. Define Mock Data
To solve the problem in the example more conveniently, we use the advanced Mock function of Apidog to provide interface data. According to the description of the problem, we need to define 5 different types of Mock data, divided into 3 successful verifications and 2 failed verifications, as follows:
When the type value is fixed, the length of values should be 1:
When the type value is range, the length of values should be 2:
When the type value is other, there is no limit to the length of values:
When the type value is fixed, the length of values is not 1:
When the type value is range, the length of values is not 2:
After defining the Mock data, you can call the interface and verify whether the data structure in the returned response is standardized.
3. Define a Successful Response
According to the requirements mentioned above, there are three corresponding situations for the expected response data and the returned response data, otherwise an error response will be returned.
3.1 Specification 1: Successful response of fixed parameter
Set the type to string type, add an enumeration value of fixed; set the values to array type, and limit the number of output elements to only 1, with string type elements inside. Details are as follows:
3.2 Specification 2: Successful response of range parameter
Set the type to string type, add an enumeration value of range; set the values to array type, and limit the maximum and minimum number of elements to 2, with string type elements inside. Details are as follows:
3.3 Specification 3: Successful response of other parameter
Set the type to string type, add an enumeration value of other; set the values to array type, with no limit on the maximum and minimum number of elements, with string type elements inside. Details are as follows:
After defining the successful response example, the user can determine whether the returned interface data conforms to the specification through the response status when making a request through the interface.
4. Verify Response Data
The response data and the returned response specification must correspond, otherwise the verification will fail. During the interface call process, it is necessary to verify and validate the returned results in a timely manner to ensure the correctness and completeness of the returned results. This can effectively reduce the probability of interface call failure or error, ensure the consistency and reliability of the interface, and reduce maintenance costs in the later stage.
4.1 Verify Specification 1
Switching "Verify Response" to "Fixed Success (200)" means that only one value in the "values" array should be output for the assertion to succeed when the type is set to "fixed".
Enter the value of 1 in the parameter field and click on the "Send" button. As the predefined response data conforms to the expected specifications, it will prompt a successful assertion ✅.
If the value of type is not fixed, the returned data structure has failed the verification ❌:
If the value of values is null or more than 1, the returned data structure has failed the verification ❌:
4.2 Range Sucess(200)
Switch the "Verify Response" to "Range Success(200)". This indicates that only two values are considered a successful assertion in the values array when the type value is a range.
If the value of type is not range, the returned data structure has failed the verification ❌:
If the value of values is null or not 2 values, the data structure verification will also fail ❌:
4.3 Other Sucess(200)
Switching "Verify Response" to "Other Success (200)" means that for the type value of other, any number of values in the "values" array will result in a successful assertion. ✅
If the value of type is not other, the data structure returned will fail the verification ❌:
Summary
In addition to the above case, you can also standardize other data structures in Apidog to check whether the interface data is standardized. Apidog also supports many other features, such as interface import, mock data, and automated testing. Click on the link to read the original article and experience it for yourself!
