1. Too long list of @RequestParams<\/h2>\n
No matter it\u2019s a controller or another class I believe you agree that a long list of method parameters is hard to read<\/b>. In addition, if parameter types are the same, it\u2019s easier to make a mistake.<\/p>\n
Static code analysis tools like Checkstyle can detect numerous inputs in methods<\/a> because it\u2019s widely considered as a bad practice.<\/p>\n It\u2019s very common that you pass a group of parameters together to different layers of your application. Such group usually can form an object<\/b> and all you have to do is to extract it and give it a proper name<\/b>.<\/p>\n Let\u2019s take a look at a sample GET endpoint used to search for some products:<\/p>\n Three parameters isn\u2019t a concerning number but it can easily grow. For instance, searching usually includes a sort order or some additional filters. In this case, they are all passed to the data access layer so they seem to be perfect candidates for parameter object<\/a> extraction.<\/p>\n From my experience, developers don\u2019t replace long lists of @RequestParams<\/i> because they simply aren\u2019t aware it\u2019s possible. The documentation of @RequestParam<\/i> doesn\u2019t mention the alternative solution.<\/p>\n Start with updating controller\u2019s method to accept a POJO as the input instead of the list of parameters.<\/p>\n The POJO doesn\u2019t require any additional annotations. It should have a list of fields which match with request parameters that will be bound from the HTTP request, standard getters\/setters, and a no-argument constructor.<\/p>\n Alright, but we don\u2019t use the @RequestParam<\/i> annotation only to bind HTTP parameters. Another useful feature of the annotation is the possibility to mark a given parameter as required. If the parameter is missing in a request, our endpoint can reject it. To achieve the same effect (and even much more!) with a POJO we may use bean validation<\/b>. Java comes with numerous built-in contraints but you always create a custom validation<\/a> if needed.<\/p>\n Let\u2019s return to our POJO and add some validation rules to fields. If you just want to mimic the behavior of <\/b>@RequestParam(required = false)<\/i><\/b>, all you need is the @NotNull<\/i><\/b> annotation on a required field<\/b>.<\/p>\n In many cases, it makes much more sense to use @NotBlack<\/i> instead @NotNull<\/i> as it also covers the undesired empty string problem (a string with the length of zero).<\/p>\n A word of caution:<\/p>\n Adding validation annotations of fields isn\u2019t enough to make it work.<\/b><\/p>\n You also need to mark the POJO parameter in controller\u2019s method with the @Valid<\/i> annotation. This way you inform Spring that it should execute validation on the binding step.<\/p>\n Another useful feature of the @RequestParam<\/i> annotation is the ability to define the default value when the parameter isn\u2019t present it the HTTP request.<\/p>\n When we have a POJO no special magic is needed. You just assign the default value directly to a field. When the parameter is missing in the request, nothing will override the predefined value.<\/p>\n You aren\u2019t forced to put all HTTP parameters inside a single object. You can group parameters in several POJOs.<\/p>\n To illustrate that, let\u2019s add sort criteria to our endpoint. First, we need a separate object. Just like before it has some validation constraints.<\/p>\n In the controller, you just add it as a separate input parameter. Note that the @Valid<\/i> annotation is required on each parameter which should be validated.<\/p>\n As an alternative to multiple input request objects we can also use composition. Parameter binding also works with nested objects.<\/p>\n Below you can find an example in which the previously introduced sort criteria was moved to the product criteria POJO.<\/p>\n To verify all nested properties, you should add the @Valid<\/i> annotation to the field. Be aware that if the field is null Spring won\u2019t validate its properties. That might be the desired solution if all nested properties are optional. If not, just put the @NotNull<\/i> annotation on that nested object field.<\/p>\n HTTP parameters must match field names using the dot notation. In our case they should look as follows:<\/p>\n Nowadays, you can observe a tendency in going away from traditional POJOs with setters in favor of immutable objects.<\/p>\n Immutable objects have several benefits (and downsides as well \u2026 but shh). In my opinion, the biggest one is simpler maintenance<\/b>.<\/p>\n Have you ever been tracking through dozens of layers of your application to understand what conditions lead to a particular state of an object? In which place this or that field changed? Why is it updated? The name of a setter method doesn\u2019t explain anything. Setters have no meaning.<\/p>\n Considering the fact when Spring framework was created, no one should be surprised that Spring strongly relies on POJO specification. Yet, times changed and old patterns became antipatterns.<\/p>\n There\u2019s no easy way to magically bind HTTP arguments to a POJO using a parameterized constructor. The non-argument constructor is inevitable. However, we can make that constructor private<\/i> (but sadly not in nested objects) and removed all setters. From the public perspective, the object will become immutable.<\/p>\n By default, Spring requires setter methods to bind HTTP parameters to fields. Fortunately, it\u2019s possible to reconfigure the binder and use direct field access (via reflection).<\/p>\n In order to configure the data binder globally for your whole application, you can create a controller advice component. You can alter the binder configuration inside a method annotated with the @InitBinder<\/i> annotation which accepts the binder as an input.<\/p>\n After creating that small class we can return to our POJO and remove all setter methods from the class to make it read-only for the public use.<\/p>\n Restart your application and play around with the parameters of the HTTP request. It should work as before.<\/p>\n In this article, you could see that HTTP request parameters bound in Spring MVC controllers using @RequestParam<\/i> can be easily replaced with a parameter object which groups several attributes and is nothing more than a simple POJO or optionally an immutable DTO.<\/p>\n You can find described samples in the GitHub repository<\/a>. I hope presented cases are self-explanatory but if there are any doubts or you would like to put your two cents in, I strongly encourage you to leave your comment below the post.<\/p>\n@RestController\r\n@RequestMapping(\"\/products\")\r\nclass ProductController {\r\n\r\n \/\/...\r\n\r\n @GetMapping\r\n List<Product> searchProducts(@RequestParam String query,\r\n @RequestParam(required = false, defaultValue = \"0\") int offset,\r\n @RequestParam(required = false, defaultValue = \"10\") int limit) {\r\n return productRepository.search(query, offset, limit);\r\n }\r\n\r\n}<\/pre>\n2. Binding @RequestParam to POJO<\/h2>\n
@GetMapping\r\nList<Product> searchProducts(ProductCriteria productCriteria) {\r\n return productRepository.search(productCriteria);\r\n}<\/pre>\nclass ProductCriteria {\r\n\r\n private String query;\r\n private int offset;\r\n private int limit;\r\n\r\n ProductCriteria() {\r\n }\r\n\r\n public String getQuery() {\r\n return query;\r\n }\r\n\r\n public void setQuery(String query) {\r\n this.query = query;\r\n }\r\n\r\n \/\/ other getters\/setters\r\n\r\n}<\/pre>\n2.1. Validating request parameters inside POJO<\/h3>\n
final class ProductCriteria {\r\n\r\n @NotBlank\r\n private String query;\r\n @Min(0)\r\n private int offset;\r\n @Min(1)\r\n private int limi;\r\n\r\n \/\/ ...\r\n\r\n}<\/pre>\n@GetMapping\r\nList<Product> searchProducts(@Valid ProductCriteria productCriteria) {\r\n \/\/ ...\r\n}<\/pre>\n2.2. Default request parameter values inside POJO<\/h3>\n
private int offset = 0;\r\nprivate int limit = 10;<\/pre>\n
3. Multiple objects<\/h2>\n
final class SortCriteria {\r\n\r\n @NotNull\r\n private SortOrder order;\r\n @NotBlank\r\n private String sortAttribute;\r\n\r\n \/\/ constructor, getters\/setters\r\n\r\n}<\/pre>\n@GetMapping\r\nList<Product> searchProducts(@Valid ProductCriteria productCriteria, @Valid SortCriteria sortCriteria) {\r\n \/\/ ...\r\n}<\/pre>\n4. Nested objects<\/h2>\n
final class ProductCriteria {\r\n\r\n @NotNull\r\n @Valid\r\n private SortCriteria sort;\r\n\r\n \/\/ ...\r\n\r\n}<\/pre>\nsort.order=ASC&sort.attribute=name<\/pre>\n
5. Immutable DTO<\/h2>\n
![\"@RequestParam\"](\"http:\/\/www.javacodegeeks.com\/wp-content\/uploads\/2018\/10\/old-pattern.jpeg\")
<\/a><\/p>\n@ControllerAdvice\r\nclass BindingControllerAdvice {\r\n\r\n @InitBinder\r\n public void initBinder(WebDataBinder binder) {\r\n binder.initDirectFieldAccess();\r\n }\r\n\r\n}<\/pre>\nfinal class ProductCriteria {\r\n\r\n @NotBlank\r\n private String query;\r\n @Min(0)\r\n private int offset = 0;\r\n @Min(1)\r\n private int limit = 10;\r\n\r\n private ProductCriteria() {\r\n }\r\n\r\n public String getQuery() {\r\n return query;\r\n }\r\n\r\n public int getOffset() {\r\n return offset;\r\n }\r\n\r\n public int getLimit() {\r\n return limit;\r\n }\r\n\r\n}<\/pre>\nConclusion<\/h2>\n