I agree that not specifying a HTTP method should be a blocking issue but that shouldn’t be the case if you explicitly specify that both GET and POST are supported. For example the OpenID-Connect /userinfo endpoint should support both GET and POST requests according to the spec (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo).
Hello,
I don’t understand the problem. The rule says:
In most cases people use only one method, and this is just a reminder “please verify if you need all those methods”. In your case you should mark it as Won't Fix because it is compliant with the specification.
I understand that I can just disable the rule for that specific line of code but I’m not a fan of that.
My suggestion was that the extension “consider narrowing this list of methods to one” should be removed because there are valid scenarios for allowing multiple HTTP methods. If a developer has explicitly indicated the allowed methods, he probably had a reason to do that so Sonar shouldn’t indicate as a blocking issue. Maybe seperate this check into a seperate rule but with a lower severity?
It’s true that it can be weird to see this message while the rule is saying “@RequestMapping methods should specify HTTP method” and you did specify the HTTP method. We wanted at some point to create a separated rule and it would have been weird to:
during one scan say: specify the HTTP method
the developer is fixing it with multiple HTTP methods
during the next scan say: you should not have more than one HTTP methods per @RequestMapping
For this reason, we decided to group together the recommendations related to HTTP verbs for @RequestMapping.