3.1. Validating HTTP requests

Then, enable validation of a particular method by decorating
it with
the
@ValidateRequest
annotation.

@PUT@ValidateRequestpublicvoid updateTask(Task incommingTask){...}

Now, the HTTP request's entity body (the
incomingTask
parameter) will be validated prior to invoking the method.

3.1.1. Validating entity body

By default, the entity parameter (the parameter with no annotations
that represent the body of the HTTP request)
is
validated. If the
object is valid, the web service method is
executed.
Otherwise, a
ValidationException
exception
is thrown.

The
ValidationException
exception
is a simple carrier of constraint violations found by the
Bean
Validation provider. The exception can be
handled by an
ExceptionMapper
or Seam Catch handler.

Seam REST comes with a built-in
ValidationException
handler,
which is registered by default. The exception handler converts the
ValidationException
to an HTTP response with the 400 (Bad request) status code. Furthermore,
it sends messages relevant to the
violated constraints within the
message body of the HTTP response.

3.1.2. Validating resource fields

Besides the message body, the JAX-RS specification allows
various
parts of the HTTP request to be injected into
the JAX-RS
resource or passed as method parameters.
These
parameters are usually
HTTP form parameters, query
parameters,
path
parameters, headers, etc.

Note

Currently, Seam REST validates only JavaBean parameters (as opposed to primitive types, Strings and so on).
Therefore, to validate these types of parameters, either use resource field
validation described
in
Section 3.1.2, “Validating resource fields”
or read further and use parameter objects.

In order to prevent an oversized method
signature when the number of
parameters is too large, JAX-RS
implementations provide
implementations of the
Parameter Object pattern
. These objects aggregate multiple parameters into a single
object, for example
RESTEasy Form Object
or
Apache CXF Parameter Bean
.
These parameters can be validated by Seam REST. To trigger the validation, annotate the parameter with a
javax.validation.Valid
annotation.

3.3. Using validation groups

In some cases, it is desired to have a specific
group of
constraints used for validation of web service parameters.
These
constraints are usually weaker than the default constraints of
a domain model.
Take partial
updates as an example.

The Employee resource in the example above is not allowed to
have the null value specified in any of its fields.
Thus, the entire
representation of a
resource (including the
department and related
object graph) must be
sent to update
the
resource.

When using partial updates, only values of modified fields
are required to be
sent within the update request, while
the non-null
values of the
received object are updated. Therefore, two groups of
constraints are
needed: group for
partial updates
(including
@Size and
@Email, excluding @NotNull) and the
default group
(@NotNull).