preface

Interface debugging is an essential skill for every software developer, and the completion of a project may take more time to test and debug interfaces than to actually develop and write code, almost every [daily work item of development].

Postman is a great choice until you taste IDEA REST, with full REST Client functionality and request history. However, postman can be discarded when using IDEA REST, because IDEA REST Client has all the features of Postman, but also features that Postman does not have.

From Postman to IDEA REST Client

There are several reasons for the law of true fragrance:

  1. First, postman has all the functions of IDEA REST Client, such as REST Client console and history request logging
  2. Second, why switch to a production tool when you can do development and debugging in one
  3. The IDEA REST Client also supports environment configuration differentiation, as well as the ability for interfaces to respond to assertions and scripting
  4. The IDEA REST Client’s request configuration can be described as a file configuration, so it can be shared with projects and project members

IDEA REST Client console

On the top toolbar, choose Tools > HTTP Client > Test RESTFUL Web Service. The interface of the IDEA REST Client console looks like the following:

As you can see, the console displays the same functionality as Postman, including the request mode, request parameters and request header padding. In particular, if the request mode is Authorization :Basic, you can click the button shown in the figure below. A window will pop up to fill in the user name and password, which will be automatically added to the Authorization header

History request record

IntelliJ IDEA automatically saves the last 50 requests executed to the http-requests-log. HTTP file, which is stored in the.idea/httpRequests/directory of the project. Using request history, you can quickly navigate to a particular response and request again.

The size of the file is as shown in the image below. Just click the run button to make the request again. If a 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

This is a complete IDEA REST Client request script. If you trigger it from the console, you can copy the history request file into the project as an HTTP request script and share it with other members. If not, You can also create a. HTTP or. Rest file. IDEA automatically identifies it as an HTTP request script.

Grammar part

POST {{baseUrl}} get? {{baseUrl}} / postcontent-type: {baseUrl}} / postcontent-type: application/x-www-form-urlencodedid=999&value=contentCopy the code

Each request body is separated by ### three hash keys, and the url and header parameters are next to each other. The request parameters, whether the body parameter of POST or the parameter parameter of GET, are wrapped

Environment to distinguish the

If you are careful, you may have noticed that the code in the above example does not have a real request address. Instead, it has a placeholder {{baseUrl}}. This is where the IDEA REST Client is really interesting. Not only can baseUrl be replaced by placeholders, but some request parameters that are relevant to the interface environment can be distinguished by configuration files.

In the first place in the HTTP with directory to create a script named HTTP – client. Private. Env. Json file, and then the content is as follows, the primary key value used to distinguish the environment, such as, dev, uat, pro, etc., Context objects are environment variables that can be retrieved in an HTTP request. You can retrieve these parameters directly in the HTTP script via {{xx}} placeholders

{ "uat": { "baseUrl": "http://gateway.xxx.cn/"."username": ""."password": "" }, "dev": { "baseUrl": "http://localhsot:8888/"."username": ""."password": "" }}Copy the code

IDEA lets you perform the configuration for that environment before choosing to execute the request, such as:

Results the assertion

The IDEA REST Client can perform scripted assertion processing on the response value of an interface, immediately moving from an interface debugging tool to a testing tool.

Such as:

### Successful test: check response status is 200GET 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 result value is temporary

If you use postman, you need to access the login interface first. After obtaining the token, you need to manually paste and copy it into the header parameter of the new debugging interface. This is too troublesome. The IDEA REST Client also has a number of features that perfectly solve this problem, as shown in the following script:

# # # demonstration POST request POST https://httpbin.org/postContent-Type: application/json {" user ":" admin ", "password" : "123456"}> {% client.global.set("auth_token", response.body.json.token); %} # # # demo GET request GET https://httpbin.org/headersAuthorization: Bearer {{auth_token}}Copy the code

At the end of the first authenticated request, we can get the token information returned in response, and then we set it in the global variable through the script. Then in the following interface request, we can directly obtain the token in the form of double curly bracket placeholder

conclusion

Postman is well known and is indeed a very good must-have tool. Before I recommended this tool to others, I always recommended postman to others. However, IDEA REST Client is really good and worth a try. Later, the amway tool was switched to IDEA REST Client, but I lost postman anyway. When interconnecting with a third party, a REST-HTTP interface request file is required in the project to satisfy the needs of others.