Jersey 1.x does not provide validation of request parameters - it leaves that up to you.
Jersey 2.x does provide validation
of request parameters. However, until 2.x becomes stable, I feel more comfortable using 1.x and doing validation on my own.
Starting from an unvalidated resource, I'll sketch out several increasingly generalized approaches to validating request parameters.
An unvalidated resource
Consider the following JSR 311 resource:
Approaches to validation
All of the approaches meet the same essential requirements:
Do not query the database if any request parameter is invalid
Return errors messages to the client if any request parameter is invalid
What varies between approaches is which components take responsibility for the following concerns:
Expression of constraints
Generating and returning error responses
Do everything in the SearchParams class
I think this approach is good for simple applications. For applications with lots of resources, with complex
validation requirements, or with resources with shared validation requirements, it may make sense to generalize
To see how this approach could become cumbersome, imagine having several other REST methods in PostsResource,
each with their own parameter object, with several Integer fields that we want to apply a minimum and maximum
constraint to. In that scenario, each parameter object would have similar validation logic as the validate
method of SearchParams. It would be much better if we could generalize the application of and validation of
minimum and maximum constraints.
Use JSR 303 bean validation
JSR 303 bean validation is awesome. It allows you to apply constraints to POJOs
with annotations, and validate them in a uniform way with a validator class. Here I declare constraints directly on
The validate method is no longer doing anything specific to SearchParams. Therefore, it could be factored to a base
class. The validator factory should also be re-used, rather than recreated each time validate is called.
(Almost) removing validation from resources
In all of the previous approaches, the PostsResource takes some responsibility for validation. It initiates the
validation process, and generates an error response if validation fails. These two responsibilities are not specific
to either PostsResource or to SearchParams, and can be factored out.
Using Dropwizard, we could remove the validate method from SearchParams entirely, and simply add a @Valid
annotation in front of the SearchParams parameter in the search method of PostsResource:
Dropwizard uses a custom subclass
of JacksonJaxbJsonProvider to check for the presence of @Valid annotations on resource method params,
validate them, and generate an error response if validation fails.
This comes with its limitations. For example, Dropwizard doesn't give you a way to customize the generation of error responses.
The AOP way
Using aspect-oriented programming, we can achieve an outcome similar to Dropwizard's: validation occurs
before resource methods are executed.
I don't understand AOP very well, and this is probably overkill for most applications.
However, this approach gives you a ton of flexibility. I'll flesh it out in another post.