Glassfish, REST and Jersey

Last week, I was working on a semi-commercial project where we are using Jersey. I didn't find too much documentation, but Jersey is open-source and the samples are pretty self-explaining.

Jersey is the Reference Implementation for JSR 311 (Java API for RESTful Web Services). I was impressed by a Jersey presentation at JavaOne --- see one of my older blogposts --- for a couple of reasons:

1. It is out of the box available in GlassFish v3 (at least in b49, but I think it is in the preview as well). Works fine on GlassFish v2 as well, but I copied the jars from my v3-install into my v2.1 install. 2. Netbeans 6.5.1 has support for Jersey. 3. The REST protocol is used in a growing number of publicly available webservices.
4. For some of the projects we do at LodgON, third parties need to integrate with some Java backend code that we provide. A REST interface is almost always warmly welcomed.
5. Our programming model that mixes page reloads and Ajax requests becomes easier.

The fifth reason was the one that convinced me to do a project on Jersey. In a number of web-based projects, we have a bunch of JSP templates. In most of these templates, user interactions can lead to either a new page being called, or to part of the page being refreshed using AJAX technology.
In most of our projects, a new page can be called in a number of ways:
  • a link to a new page is clicked. Often, the linked page is a servlet that gets called after a number of filters are called, and the servlet forwards or redirects the user to a new JSP.
  • an HTML Form is submitted, resulting in a servlet call that also forwards or redirects the user to a new JSP after some processing is done.

When parts of a page are being refreshed as the result of an Ajax call, the servlet that receives the Ajax XMLHttpRequest should not redirect or forward a new (HTML) page, but should return some XML information.

It is often not clear in the beginning of a project what the best approach is for a particular data-operation: loading a new page, or using Ajax. Typically, during the iterations that precedes the deliverable, requirements change and what was originally a page refresh should all of a sudden be an Ajax call.
We solved this in a number of cases by using a request parameter format which could be either "HTML" or "XML". But this leads to rather ugly tests in the servlet request processing methods.

Jersey (or JSR 311) does not solve the problem of changing requirements, of course, but it provides a number of annotations that can be used for dispatching the request to the appropriate method, depending on the information in the request headers. For instance, a request coming from a web browser will contain a header that has at least something like "Accept:text/html". A request coming from e.g. the jquery javascript library using $.getJSON has a header "Accept:application/json". We don't have to check these headers manually anymore, nor do we have to provide a formatting parameter. Instead, we use the @Produces annotation to indicate the output format a particular method will provide. We can have two methods for e.g. inviting a friend, one as the result of an Ajax call and one as a result of a form submission. Most of the business logic will be the same (and can be handled in a private method), but the @Produces annotation on the methods will be different.

This is only one of the advantages of Jersey. While using Jersey, I discovered other nice features, I will discuss some of them in future blog posts.

written on 26 Jun 2009 22:07.

no comments

Create comment