It is common to use abbreviated names for query parameters in GET
requests.
For example:
GET /search?q=java&y=2019&l=eng
Where q
means query, y
means year, and l
means language.
This can then be handled using a controller method:
public SomeResponse search(SearchRequest request) {
...
}
where:
public class SearchRequest {
private String q;
private String y;
private String l;
}
However if we could apply @RequestParam
on fields, then we could make SearchRequest
more readable:
public class SearchRequest {
@RequestParam("q")
private String query;
@RequestParam("y")
private String year;
@RequestParam("l")
private String language;
}
As shown in the linked SO post, it is possible to customize Spring to do this using a custom annotation (e.g. @ParamName
), but I think it would be cleaner and more elegant to allow @RequestParam
(and @PathVariable
, etc.) on POJO fields.
References
Comment From: nictas
This issue is a possible duplicate of https://github.com/spring-projects/spring-framework/issues/23094 and https://github.com/spring-projects/spring-framework/issues/21770, but I would really like to see it implemented. Not only will it solve the issue with shortened parameter names, but it would also allow us to construct a POJO from headers/parameters with names that are not legal Java identifiers (for example "x-cf-applicationid").
Comment From: behrangsa
Also related: https://github.com/spring-projects/spring-framework/issues/22047.
Comment From: rstoyanchev
This should be considered together with #22047 indeed, and there are also #23094 and #21770 that can be considered superseded.
Comment From: stdevi
Hi, could you provide any recommendation on how to start proceeding with this feature?
Comment From: Johnny850807
Hi, I'm new here.
I'm wondering if is it a good idea to introduce a new annotation like @ParamName
and use it with @RequestParam to address the scenario mentioned in the original post. Here's an example:
public SomeResponse search(@RequestParam SearchRequest request) {
...
}
public class SearchRequest {
@ParamName("q")
private String query;
@ParamName("q")
private String year;
@ParamName("q")
private String language;
}
Comment From: jhoeller
We have no plans to introduce field-level request binding annotations. @RequestParam
, @PathVariable
and co are meant to be used at the parameter level, that's a pretty central part of our annotated handler method arrangement. Binding to objects is a separate mechanism based on bean property setters, property-style fields or constructor arguments, matched against request parameters and path variables. If different binding names are intended there, you could use constructor binding and declare the constructor parameter names with the abbreviated binding names, or with setter methods and declare the setter method names according to your binding names, all while keeping the field names themselves readable.
Comment From: vcruzmj
I know this is a closed issue, but it would be nice to implement some alternative at a field
level in scenarios where you have too many params as @RequestParams
, mainly because of kotlin
; usually, these DTOs are created in data classes, and the @ConstructorProperties add back all the verbose that the data classes are trying to remove. Also, but not less important, it leads to human error more easily than a field-level annotation.
Comment From: mammadyahyayev
It would be great if this is supported by default, but you can achieve the same thing with custom method argument resolvers. You can read my solution from here: https://stackoverflow.com/a/79132213/13452926