preface
Interface debugging is an essential skill for every software development practitioner. The completion of a project may take more time to debug interface tests than the actual development of the code. It is almost a daily work item of every development. Before you taste IDEA REST, Postman is a great choice with full REST Client functionality and request history. But when you use IDEA REST, postman can be lost, because the IDEA REST Client has all the functions of Postman, plus some that Postman does not.
From Postman to IDEA REST Client
There are several reasons for this:
- First of all, postman has all the functions of IDEA REST Client, such as REST Client console and historical request record
- Second, why switch to another production tool when you can do development and debugging in one
- Then the IDEA REST Client also supports environment configuration differentiation, as well as the ability to assert and script interface responses
- IDEA The request configuration of the REST Client can be described as a file configuration, so it can be shared with the project and project members
IDEA REST Client console
Choose Tools > HTTP Client > Test RESTFUL Web Service from the top-level toolbar. After the IDEA REST Client console is opened, the page is as follows:
As you can see, this console shows the same functional area as Postman, including the request mode, request parameters, and request header padding. In particular, if the request mode is Authorization :Basic, click the button shown in the following figure. A window will pop up to fill in the user name and password, which will be automatically added to the Authorization header
Historical request record
IntelliJ IDEA automatically saved the most recent 50 requests to the http-request-log. HTTP file stored in the project’s.idea/httpRequests/directory. Using the request history, you can quickly navigate to a specific response and issue the request again. The file size is as shown in the image below, and to make a request again, just click the run button. If the request is made again from the request history, a link to its execution information and response output is added to the top of the request history file.
Build the HTTP request script
The above history is a complete IDEA REST Client request script. If you triggered the request from the console, you can directly copy the history request file into the project as the HTTP request script and share it with other members. If not, You can also create a. HTTP or. Rest ending file and IDEA will automatically identify it as an HTTP request script.
Grammar part
POST {{baseUrl}}}get? Show_env =1 Accept: application/json {"name":"a"} ## application/x-www-form-urlencoded id=999&value=contentCopy the code
Each request body is separated by the hash key ###. The REQUEST URL and header parameters are next to each other. The request parameters, whether the body of POST or the parameter of GET, are newline
Environment to distinguish the
If you look carefully, you may notice that the code in the above example does not have a real request address. Instead, there is a placeholder for {{baseUrl}}. This is where the IDEA REST Client is very interesting. Not only can baseUrl be replaced with a placeholder, but some of the request parameters can be identified by the configuration file if they are relevant to the interface environment.
Create a file named http-client.privately.env. json in the same directory as the.http script. Create a file named http-client.privately.env. json in the same directory as the.http script. An environment object is an environment variable that can be obtained in an HTTP request. You can use the {{xx}} placeholder in the HTTP script of the request to obtain the configured parameters
{
"uat": {
"baseUrl": "http://gateway.xxx.cn/"."username": ""."password": ""
},
"dev": {
"baseUrl": "http://localhsot:8888/"."username": ""."password": ""}}Copy the code
When choosing to execute a request, IDEA will let you choose which environment configuration to execute, such as:
Results the assertion
The IDEA REST Client can perform scripted assertion processing against the response values of the interface, immediately moving from an interface debugging tool to a testing tool. For example:
### Successful test: check response status is 200
GET https://httpbin.org/status/200
> {%
client.test("Request executed successfully", function() {
client.assert(response.status === 200, "Response status is not 200");
});
%}Copy the code
The resulting value is stored temporarily
Imagine a scenario where a system needs to be authenticated to access it. If you use Postman, do you first access the login interface and then manually paste and copy the token into the header parameter of the new debugging interface? IDEA REST Client also has a nice feature that can solve this problem perfectly. See the script below:
POST https://httpbin.org/post content-type: application/json {"user": "admin", "password": "123456" } > {% client.global.set("auth_token", response.body.json.token); %} # # # demo GET request GET https://httpbin.org/headers Authorization: Bearer {{auth_token}}Copy the code
After the end of the first authentication request, we can get the returned token information in the response, and then we set it in the global variable through the script, so in the following interface request, we can directly use the double-curly bracket placeholder to get the token
conclusion
Postman has a reputation for being a really good, must-have tool, and it’s always been recommended by Amway Postman. However, IDEA REST Client is really good and worth a try. Later amway switched to IDEA REST Client, but I lost Postman anyway. When interconnecting with a third party through an interface, a REST-HTTP. HTTP interface request file is required in the project to satisfy yourself and facilitate others.
More wonderful articles, pay attention to [ToBeTopJavaer], more tens of thousands of high-quality course resources free waiting for you to take!!Copy the code