Debug
After developing the interface, use API debugging to quickly verify its functionality.
The functionality is divided into three major areas: Request Address, Request Area, and Response Area.
Request Address
Method: Supports a dropdown selection of various Method request methods.
URL: You can directly enter the interface's request address in the address bar.
Protocol: Currently supports sending of http1.1 and http2 protocols.
Request Area
You can visually define the interface's request header, query, and other input parameters. Use the global parameter feature to set common parameters across the entire project quickly.
Header
Header input parameters: Support for quickly searching common header parameter names and entering request parameter values.
Query
Query input parameters: The set query parameter values will automatically be appended to the URL address; and you can define whether to append an "=" sign when the parameter value is empty through the setting of "=".
Body
Supports multiple data formats: none
, form-data
, x-www-form-urlencoded
, binary
, msgpack
, raw (json/xml/javascript/plain/html)
.
- none: there is no request body.
- form-data: supports file uploads and content type selection. Switch to form-data when you need to submit a form with files.
- urlencode (x-www-form-urlencoded): Switch to urlencoded when you need to submit a form.
- binary: When you need to upload a binary file
- msgpack
Generate values based on the defined schema.
- raw: When you need to send a JSON object or other objects, switch to the corresponding raw type.
- raw (json/xml) , supports schema edit for hierarchical interface parameters in json or xml.
Generate values based on the defined schema.
- raw (javascript/plain/html) supports source code editing for designing parameter values.
Path
Supports RESTful API design by adding variables in the path using {}
or :
. These variables will be displayed in the input parameters.
Authentication
Supports Bearer token, Basic auth, Digest auth, OAuth 1.0, Hawk authentication, AWS Signature, NTLM Authentication (Beta), Akamai EdgeGrid and other authentication methods.
Cookie
Supports directly entering the request content of cookies.
Pre-request/Post-response
Pre-request operations occur before the request is sent. These operations support custom scripts and database connections, often used for setting input parameters or printing data.
Post-response operations occur after the request is sent and are typically used for setting variables or making assertions. They support custom scripts, database connections, and variable extraction.
- Support drag sorting, name modification, and deletion
- The switch indicates whether to perform this task
Response Area
Real-time Response
Response body & Test results
Response headers
Response cookie
Actual Request
Console
The console can view the content printed by pre-request and post respons scripts.
Proxy and Response Time
If you've configured a proxy in the system settings, you can verify its effectiveness in the response area. Additionally, you can refer to the documentation for detailed instructions on using a proxy.
Click on the response time to view the duration of each event:
Request: Time from sending the request to initiating the socket operation. Socket: Duration of the socket operation. Lookup: Time taken for DNS query. Connect: Time required to establish a connection to the server. SecureConnect: Time to establish an SSL secure connection. Response: Time to receive a response from the server. End: Time taken to conclude the request. Done: Total time for the entire request processing.
These time metrics help analyze network request performance, identifying which stages are taking the longest. If a particular stage is found to be slow, further optimization may be needed.