Question

I’m building a REST webservice in Java using Spring, Jersey and Hibernate (JPA).

Now I’m trying to add support for validation in my resources. JSR-303 (Bean validation) naturally appeared as a suitable choice (I’m using Hibernate Validator which is the reference implementation of JSR-303). However, I’m trying to consolidate some concepts first.

It seems to me that there are at least two kinds of possible validations:

• Regular validation on fields, e.g. check that a property isn’t null, check if a String property is a valid e-mail, check if an Integer property is greater than 10, etc. This is working as expected. I’ve registered a JAX-RS ExceptionMapper which maps javax.validation.ConstraintViolationException‘s into proper HTTP responses.
• Data Integrity Validation

I’ll explain what I mean exactly by “Data Integrity Validation” with an example. This happens when there are relationships between two or more resources. Imagine two resources: a Product and a Category. A Product has a Category. When the client sends to the server the representation of the Product to create (a POST HTTP request), it must inform the Category of the product. The client must know the categories beforehand, of course. Imagine in JSON something like:

{
   "quantity": "10",
   "state": "PRODUCED",
   "category": {
      "id": "123"
   }
}

Well, the category with id 123 might not exist. If we try to insert this into the database, obviously we get a foreign key related exception. So I assume we have to validate these issues and return a proper message to the client, just as in regular property validations.

---

Now, my main questions are:

1. Right now I’m performing the validation in the Data Access level, through JPA’s integration with Bean Validation. Should the validations be done before/after serializations processes, before/after database operations or both?
2. How to handle Data Integrity Validations? Manually? (i.e. explicitly consulting the database checking data integrity) Or should we just try to insert it anyway and then catch database (or DAO) exceptions? Bean Validation has nothing to do with this kind of validation, right?
3. If you have any experience with JAX-RS/REST and Bean Validation I would be glad if you let me know. Using groups?

These questions are somewhat related to Java, but I was also hoping to get some new perspectives on these matters. Some technology independent ones. 🙂
It would be great if you could provide your own solutions for these problems on your REST webservices.

Answer 1

The solution ended up to be subclassing Jackson’s JacksonJaxbJsonProvider which implements a JAX-RS MessageBodyReader and MessageBodyWriter.
I was inspired by the amazing dropwizard’s approach. In this provider we need to somehow Inject a Validator instance (I used Spring for Injection and Hibernate Validator for JSR-303 implementation). If you use Hibernate ORM don’t forget to disable entity validation, otherwise you will be validating the same entity twice. It may be what is desired, though.

Then, in this subclassed MessageBodyReader, I validate the object and throw a custom InvalidEntityException with the errors from the validator. I also created a JAX-RS ExceptionMapper<InvalidEntityException> that maps every InvalidEntityException into a proper HTTP response. In my case I returned a Bad Request and a JSON object containing the errors description.

Notice that this MessageBodyReader checks for @Valid and @Validated annotations. This means that it correctly supports groups. This is important because we probably don’t want to do the same kind of validation across our entire application. An example is when we want to do a partial update (PUT). Or, for example, an id property must be null in a POST request but non-null everywhere else.

Data Integrity Validations aren’t completely dealt with yet. But I’m planning to catch database exceptions and converting them to my own domain exceptions (say a DataIntegrityException) as it seems more efficient and loosely coupled to me.

---

UPDATE:

Since JAX-RS 2, the recommended way to do this is to use its Bean Validation support. Check here: https://jersey.java.net/documentation/latest/bean-validation.html