20

I am thinking of two options for handling query/request parameters:

  1. Map individual parameters to corresponding the method parameters:
@GET
public String blah(@QueryParam("testParam") String testParam) {

}
  1. Map all parameters to the properties of a Java bean:
@GET
public String blah(@BeanParam RequestParamBean bean) {

}

The second option seems more attractive as it allows the validation logic of input query parameters to be moved and decoupled from the blah method whose core responsibility should be to process and delegating the validation to a validator should high degree of decoupling (and also SOLID principle, right?).

However, most of the examples I see (in fact, the existing project I am working on) use only the first option. I am wondering if is there any reason why the second option is not widely used? Are there any pitfalls? Is this an anti-pattern? Is this against any best practice?

cassiomolin
  • 124,154
  • 35
  • 280
  • 359
user1539343
  • 1,569
  • 6
  • 28
  • 45

1 Answers1

30

The @BeanParam annotation was introduced in JAX-RS 2.0 as a parameter aggregator (which means it cannot be used in JAX-RS 1.0).

The idea behind the @BeanParam annotation is to have a Java class to aggregate parameters annotated with @XxxParam annotations. The following @XxxParam annotations can be used to annotate the fields of a parameter aggregator class:

Besides fields annotated the @XxxParam annotations, the parameter aggregator class can have fields annotated with the @Context annotation. For a list of types that can be injected with the @Context annotation, check this answer.

I believe it's just a matter of convenience and preference of the developers. In many situations, a class to aggregate parameters is not necessary. The use of the @XxxParam annotations in method parameters is very handy.

But when you need to reuse parameters in different methods or the method has many parameters annotated with @XxxParam annotations, go for the @BeanParam approach.

In your question, you mentioned the SOLID principle. But don't forget the KISS principle :)

Start with the @XxxParam annotations in your method parameters and don't overuse the @BeanParam annotation trying to solve a problem you don't have. You always can refactor your code to create a parameter aggregator class if you need it.

cassiomolin
  • 124,154
  • 35
  • 280
  • 359
  • 1
    Thank you very much for your response. I don't understand the last paragraph. The reason I want to use @BeanParam is to delegate the validation logic elsewhere as more of the 50% of the code in a method is used for method parameter validation. Besides the input parameter validation is inconsistent across different methods - ie some methods don't test at all. So if we have a mechanism that would ensure that we accommodate all these situations that would be great. – user1539343 Jul 06 '16 at 15:17
  • @user1539343 If the `@BeanParam` provides what you need, use it :) – cassiomolin Jul 06 '16 at 15:26