The Content-type=application/json of process analysis of interface parameter resolution in SPRINGMVC

The previous blog analyzed the parameter resolution in Content-type by default. Today, let's look at what happens when you specify Content-type as Application/json. Compared with the previous default, there is a difference in the place below. Request.getparameternames () in the default content-type=application/x-www-form-urlencoded; The value can be obtained when charset=utf-8, but not in the case of Content-type=application/json. By querying the data, Tomcat treated the content-type=application/x-www-form-urlencoded with special treatment, Content-type not application/ The x-www-form-urlencoded POST request does not read the request body data and does the corresponding parameter processing, that is, the form data is not parsed to be placed in the request parameter map. So through Request.getparameter (name) is not available. Therefore, there is no argument to parse when there is no backend @responsebody this annotation.

Next we look at the addition of @responsebody after the analysis of the parameters. In the following position, the situation has changed, if the Springmvc method parameter is preceded by a @responsebody, the resolver implementation class will not add this annotation. This resolver is an example of servletmodelattributemethodprocessor when no annotations are added, and resolver is an instance of Requestresponsebodymethod after adding annotations.

Therefore, in the Requestresponsebodymethod class in the Resolveargument method to parse the parameters,

As you can see from this readwithmessageconverters method, this is read through the IO stream

The Content-type=application/json of process analysis of interface parameter resolution in SPRINGMVC