How to handle Resource validation in REST webservices?

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.

Solution 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

Solution 2

You can now use Jersey 2.0 for validation of resource arguments via JSR-303/JSR-349.

https://jersey.java.net/documentation/latest/bean-validation.html#d0e9301

Solution 3

You can make use of jersey filters, where you can make some validations on your request data.

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.

For such cases, one can rely on the validations on data access level. But if you want to respond to your client synchronously, it is usually better to have this business logic exposed by some service API. i.e. You may have an API like isValidCategory(int id), which can be queried at a higher level than DAO so that you don't really have to wait till the data access layer encounters an error/exception. Obviously, this can still mean a database lookup (depends on your system), but optimizing that to improve your response time using Caching or some other mechanism is an entirely different problem altogether.

Talking about bean validators, you can take a look at Hibernate Validator which is a JSR 303 implementation.

Comments

[miguelcobain]

As far as I know, jersey filters don't have access to the unmarshaled object (bean). So, how would you use a validator in a jersey filter? Like I said, I'm using Hibernate Validator.

[miguelcobain]

If you had that problem, where are you doing your data integrity validations?

[user2416728]

can u give a look at this question about rest webservice : stackoverflow.com/questions/17233358/…

[Evgeny Makarov]

do you have a working code example subclassing JacksonJaxbJsonProvider?

[miguelcobain]

@EvgenyMakarov, I can give you that. However, please consider using Jersey 2 (JAX-RS 2) support for bean validation. It is something much cleaner. I updated my answer. Take a look: jersey.java.net/documentation/latest/bean-validation.html