How to deal with @ ApiImplicitParam's intrusion into @ RequestParam's required attribute? 02/24 Update SLTechnology News&Howtos

How to deal with @ ApiImplicitParam's intrusion into @ RequestParam's required attribute?

2025-02-24 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

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

This article mainly explains "@ ApiImplicitParam how to solve the required attribute intrusion of @ RequestParam". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor take you to learn "@ ApiImplicitParam how to solve the intrusion of the required attribute of @ RequestParam"!

The origin of the problem

When building a project using SpringCloud, it is recommended to use Swagger to generate corresponding interface documents. Swagger can provide page access and debug the interface of the back-end system directly on the web page, which is very convenient. Recently, however, we have encountered a somewhat confusing problem. The example of the demonstration interface is as follows (the original functional interface has business implementation logic, which is simplified here):

/ * *

* @ description: demo class

* @ author: Huang Ying

* * /

@ Api (tags = "demo class")

@ RestController

@ Slf4j

Public class DemoController {

@ ApiOperation (value = "test interface")

@ ApiImplicitParams ({

@ ApiImplicitParam (name = "uid", value = "user ID", paramType = "query", dataType = "Long")

})

@ RequestMapping (value = "/ api/json/demo", method = RequestMethod.GET)

Public String auth (@ RequestParam (value = "uid") Long uid) {

System.out.println (uid)

Return "the uid:" + uid

}

The problem lies in the required requirement of the interface parameter uid. The @ RequestParam annotation defaults to true and requires it to be required, but the @ ApiImplicitParam annotation defaults to false and is not required. When the business interface carries out joint function debugging, uid can get a null value. According to the general cognitive habit, the main function of @ ApiImplicitParam annotation is to generate interface documents, which should not be intrusive to the attributes of @ RequestParam. The current feedback bug Makes me wonder if @ ApiImplicitParam will hack into the require attribute of @ RequestParam?

Framework selection, version and main function project construction

SpringBoot version: 2.1.6.RELEASESpringCloud version: Greenwich.SR3

Service module

Swagger used by SpringCloud service module:

Swagger bootstrap ui 1.9.6 enhanced swagger ui style spring4all-swagger 1.9.0.RELEASE configuration swagger parameters, eliminating code development

Service gateway

Swagger used by SpringCloud service gateway:

Knife4j 2.0.1 enhanced swagger ui style (gateway is built with gateway, swagger uses knife4j-spring-boot-starter dependency, and swagger documents of business modules can be aggregated)

This time, the scope is only for the SpringCloud business module, and does not involve the Swagger documents of the service gateway for the time being.

Testing tool

Currently, there are two testing tools: swagger doc: access using a browser, as shown below:

Postman: configure API parameters manually, for example:

Case practice Interface Test 1

As shown in the opening section, we first use the following APIs, all using default values, that is, @ ApiImplicitParam has a required of false,@RequestParam and a required of true:

@ ApiOperation (value = "test interface")

@ ApiImplicitParams ({

@ ApiImplicitParam (name = "uid", value = "user ID", paramType = "query", dataType = "Long")

})

@ RequestMapping (value = "/ api/json/demo", method = RequestMethod.GET)

Public String auth (@ RequestParam (value = "uid") Long uid) {

System.out.println (uid)

Return "the uid:" + uid

}

Look at the results of swagger:

Look at the results of postman:

Interface Test 2

Let's change the value of @ ApiImplicitParam to true,@RequestParam and restart the module @ ApiImplicitParam (name = "uid", value = "user ID", paramType = "query", required = true, dataType = "Long")

Look at the results of swagger:

By debugging the browser, we can find that the null check is completed by js, and after js determines it to be empty, it does not initiate a request to the backend, so we can think that the required parameter @ ApiImplicitParam in the swagger is valid.

Interface Test 3

Earlier, when we used the postman test interface, we found that the parameter item was empty. After we added the parameter, but did not write the value test, the result was surprising:

And no matter how the value of @ ApiImplicitParam is modified, the result is the same. there must be something wrong, which leads to our misjudgment.

Later, when we carefully checked the data, we found that we misunderstood the required parameter of @ RequestParam. This required means true: the name of the interface parameter must exist, but it doesn't matter whether there is a value after the parameter. Take the example just now:

These two requests are approved:

Localhost:8080/api/json//demo?uid

Localhost:8080/api/json//demo?uid=

Only this kind of request is not approved:

Localhost:8080/api/json//demo?

Small conclusion

Through the test scenarios of the above three interfaces, we can make at least three points clear:

The required parameter of @ ApiImplicitParam does not intrude on the read value of @ RequestParam, and they are not related.

The required parameter of @ ApiImplicitParam will affect the js logic judgment of swagger doc. The null check is done at the js level.

By default, the required parameter of @ RequestParam only verifies whether it has the parameter name, not whether it has a value.

Source code analysis swagger part

In the previous section, it was mentioned that swagger reads the required parameters of the @ ApiImplicitParam annotation, which will eventually be reflected on js and tracked to the swaggerbootstrapui.js file by browser F12. Here is an excerpt of some source codes:

# when you click the send button, read the parameter information line by line and extract the required parameter

ParamBody.find ("tr") .each (function () {

Var paramtr=$ (this)

Var cked=paramtr.find ("td:first") .find (": checked") .prop ("checked")

Var _ urlAppendflag=true

/ / that.log (cked)

If (cked) {

/ / if selected, pay attention to the required:paramtr.data ("required") information extraction for this line

Var trdata= {name:paramtr.find ("td:eq (2)") .find ("input"). Val (), in:paramtr.data ("in"), required:paramtr.data ("required"), type:paramtr.data ("type"), emflag:paramtr.data ("emflag"), schemavalue:paramtr.data ("schemavalue")}

/ / that.log ("trdata....")

/ / that.log (trdata)

/ / obtain key

/ / var key=paramtr.find ("td:eq (1)") .find ("input") .val ()

Var key=trdata ["name"]

/ / obtain value

Var value= ""

Var reqflag=false

/ / the following code is omitted

}

})

To determine whether the attribute required is processed by true on js, the js source code is as follows:

/ / determine whether it is required

If (trdata.hasOwnProperty ("required")) {

Var required=trdata ["required"]

If (required) {

If (! reqflag) {

/ / must verify whether value is empty

If (value==null | | value== "") {

Validateflag=true

Var des=trdata ["name"]

/ / validateobj= {message:des+ "cannot be empty"}

Validateobj= {message:des+i18n.message.debug.fieldNotEmpty}

Return false

}

SpringCloud service module part

Swagger frontend js verifies that when you can send a request to the backend or use postman to send a request to the backend system, you can start a series of filters and Servlet processing in the background, and there are many things to do:

/ / the actual business method section

Auth:28, DemoController (com.hy.demo.controller)

Invoke0:-1, NativeMethodAccessorImpl (sun.reflect)

Invoke:62, NativeMethodAccessorImpl (sun.reflect)

Invoke:43, DelegatingMethodAccessorImpl (sun.reflect)

Invoke:498, Method (java.lang.reflect)

/ / extraction and control of request parameters

DoInvoke:190, InvocableHandlerMethod (org.springframework.web.method.support)

InvokeForRequest:138, InvocableHandlerMethod (org.springframework.web.method.support)

InvokeAndHandle:104, ServletInvocableHandlerMethod (org.springframework.web.servlet.mvc.method.annotation)

InvokeHandlerMethod:892, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)

HandleInternal:797, RequestMappingHandlerAdapter (org.springframework.web.servlet.mvc.method.annotation)

Handle:87, AbstractHandlerMethodAdapter (org.springframework.web.servlet.mvc.method)

/ / the following are the filters of various basic Web service components, which don't care for the time being.

DoDispatch:1039, DispatcherServlet (org.springframework.web.servlet)

DoService:942, DispatcherServlet (org.springframework.web.servlet)

ProcessRequest:1005, FrameworkServlet (org.springframework.web.servlet)

DoGet:897, FrameworkServlet (org.springframework.web.servlet)

Service:634, HttpServlet (javax.servlet.http)

Service:882, FrameworkServlet (org.springframework.web.servlet)

Service:741, HttpServlet (javax.servlet.http)

InternalDoFilter:231, ApplicationFilterChain (org.apache.catalina.core)