My journey with REST

The transition from Web Services...

I have been working closely with web services and the Java WS-* set of technologies since their inception. It has often occurred to me that the contractual interface required to build simple services, like a simple echo service, was far too complex to build, write and unit test when working with web services and a simpler dialect was needed. Historically, special tooling was almost always needed to assist with the creation of the required WSDL, XSD and SOAP messages to test with. Later EJBs tried to make life easier for building web services as POJOs, however, in practice still required WSDL-first development in many cases since the auto-generation of WSDLs and XSDs from EJB method signatures could often not guarantee WS-I compliance. Java now provides many standards and different implementations for how to host web services - e.g. EJB, servlets, JBI, SCA, {your app server}, {your ESB}, BPEL engines, OpenESB, Axis, CXF, Mule and the list goes on.

... to RESTful services

Then thanks to Roy Fielding's dissertation, along came REST, and although it was always there to begin with, the complexity of the WS-* specification and need to actually build web services for the web (e.g. Twitter API) fuelled the need and adoption for 'looser' RESTful services. Google quietly dropped their SOAP search API back in 2006 in favour of a RESTful approach and have not looked back since.

WS-* has its uses and let's not forget that - I wouldn't expose a complex message format interface to a corporate HRM system using REST. This trend of reducing complexity and consideration of REST has led to what I hope will be a generally-adopted standard for writing RESTful services in Java, using JAX-RS.

Why JAX-RS?

JAX-RS (JSR 311) is the Java API for RESTful Web Services. I don't quite know why it falls under the JAX (Java API for XML) branch, since it doesn't mandate XML but I think I know why Java developers needed something like JAX-RS. To build REST-based applications in the past, you had to do some low-level things with servlets which could get quite ugly (errr...how do I assign regular expressions as servlet mappings in web.xml?) and would no doubt end up reinventing the wheel on each new project. Looking at some of the innovation happening in the industry with clean approaches to building RESTful applications from the ground-up, such as Ruby on Rails, and the plethora of proprietary Java web frameworks out there, it was apparent that Java developers needed some standards to meet the demand for the growing trend of RESTful applications. Since its inception in 2007, the JAX-RS expert group has done a great job in my opinion by giving Java developers a simple and flexible approach for developing RESTful applications. From my experience so far, Sun's "reference implementation"(1) in Jersey is feature-rich, robust, makes testing very easy and has a great community following with hooks to many other popular open source projects, all making for a very active and responsive community which has caught my attention as of late.

(1) I don't like calling Jersey the reference implementation here due to the stigma associated with that.


SOA vs ROA

At JavaOne 2009, I attended a number of talks on REST and JAX-RS. All were very good and each of the speakers tried to promote REST but distance themselves from the ongoing REST vs WS-* debate. I particularly enjoyed Paul Sandoz and Mark Hadley's introduction to JAX-RS and Jersey. Doug Tidwell did a great job of evangelizing about REST and used Adam Koford's HTTP error codes images to very amusing effect.

The general consensus with REST vs WS-*, as with most technology debates, seems to be that each have their merits and it really depends on what you're doing. I would go as far to say that there isn't really a comparison to be made here that is any different from comparing something like JMS to WS-*. They are just both ways of delivering SOA, with relative merits and weaknesses. Given that REST services normally piggy-back off HTTP and can be accessed via URLs, they are particularly suited to web resources rather than services and can take advantage of the well-defined HTTP specification to handle things such as hyperlinks, error codes, redirects to newly-created resources etc.... The hype in the industry around REST and its suitability to HTTP resources for the web has led to the introduction of more catchy acronyms such as - Resource Oriented Architectures (ROA), Web Oriented Architectures (WOA).

RESTful solutions and the JAX-RS implementation is appealing to Java developers who just like simple solutions to simple problems. I'm a big fan of reducing complexity where possible and very much like what I see so far. And so my journey begins with REST...

In my next post, I'll start to look at JAX-RS and Jersey in more detail.