Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what postman needs to pay attention to when using @ResquetBody and @RequestParam". In daily operation, I believe many people have doubts about what problems postman needs to pay attention to when using @ResquetBody and @RequestParam. Xiaobian consulted all kinds of information and sorted out simple and easy operation methods. I hope to help you answer the doubts about "what postman needs to pay attention to when using @ResquetBody and @RequestParam"! Next, please follow the small series to learn together!

1. preface

After the separation of the front and back ends, most of the data in json format is used for interaction, and the Java background generally uses the @ResquetBody and @RequestParam annotations to receive parameters.

Conventional practice is:

@ResquetBody is used to receive a complex wrapper type, such as:

@RequestBody AuthApplyDto authDto@Datapublic class AuthApplyDto { private int id; private String status=""; private String userId=""; ...}

@ResquetParam is used to receive primitive types or primitive types and String objects. Of course, if the request parameters are not complex, using multiple @ResquetParam can achieve the same effect as @ResquetBody (if the parameters are not many).

However, it is likely that you will encounter the following situation:

"Required String parameter 'userid' is not present"

At this point, you need to revisit the use of these two annotations.

2. @ResquetParam vs.@ResquetBody Test Verification Scenario 1: Use @ResquetParam annotation, test tool: postman.

Background parameters are received as follows:

@RequestParam(name="userid") String userId, @RequestParam(name="resourceid") String resourceId)

Case 1: get mode request, request parameters are as follows:

{"userid":1,"resourceid":"18"}

Test results: background can receive.

Case 2: Post mode request, JSON serialization transmission, request parameters as above. The background error is as follows:

Hehe, these several meanings, obviously passed userid, but prompt me not to pass, unscientific ah!!! Thinking about it carefully, the problem must be in the analysis of parameters in the background.

Case 3: Note also that if form-data is used, the request can be successful.

Case 4: If you use x-www-form-urlencoded, you can also successfully request

Then why is it that the same post request, json format data can not be parsed? This is because the third and fourth types are submitted as form data, and content-Type is not application/json. For more details, see: Four Common POST Methods of Submitting Data

That is to say, Content-Type = application/x-www-form-urlencoded (or multipart/form-data) encoding method, both are form requests, you can use @RequestParam to obtain parameters one by one. When Content-Type = application/json, the parameter cannot be obtained. and it's going to go wrong:

- Required String parameter 'xx' is not present

For application/json code, how should I receive it? The answer is @RequestBody. This annotation can be decoded and encoded in json format.

Scenario 2: Use @ResquetBody annotation, test tool: postman.

Background parameters received:

@RequestBody AuthApplyDto authDto

Case 1: json format transmission, post request, test result successful.

Case 2: What happens if you use @RequestBody to receive arguments and post the request in the form format? The answer is no.

Case 3: What happens if the request method is get and the background parameter receives @RequestBody in the following format? The answer is yes.

The test results are as follows:

3. Dry goods summary: For @RequestParam annotation, get request is fully supported. For post request, only data in form format can be received. For json serialized data, it is not supported. For @RequestBody annotation, get request is fully supported. For post request, only json serialized data can be received, and data in form format is not supported.

Question, how do these two annotations do adaptation parsing at the bottom?

4. Finally, make a little note.

If the requested data is an array, for example:

{ "ids":[1,2]}

Backstage needs to do the following packaging, you can receive.

@RequestBody DeleteIds ids,@Data public class DeleteIds { private Set ids; } At this point, the study of "what to pay attention to when using @ResquetBody and @RequestParam by postman" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.