I went to MuleCon 2008 and got to meet not only a lot of cool Mule engineers and users, but also Dan Diephouse, the original author of CXF. The Mule people have a really active and energetic community and are now supported by a company called MuleSource, which employs many of the Mule engineers. Among the many topics that came up, one that I took interest in was REST. I asked Dan about the REST support in CXF, which I didn’t know a lot about when I asked. He said that they had an HTTP binding, but recommended going toward JAX-RS.

Coincidentally, one of our customers actually asked the next day about using the HTTP binding with CXF! So I had a look at it and it’s basically right on. It’s annotation based and uses Codehaus’ Java REST annotations (JRA). It’s a small set of method annotations first consisting of GET, PUT, POST, and DELETE to specify which HTTP method will get you to this Java method. Next, there’s a way to map the path and headers to method arguments. That’s it. And that’s pretty much all you need.

Now, I’ve looked at JAX-RS and while I’ll admit that conceptually it’s closer to the original intention of REST, I think it makes things way too complicated. Most of the people using REST do not truly understand the notion of resources and verbs and all that good stuff. They just see the power of passing different parts of a URL to a certain method. When it comes down to the implementation of most normal REST schemes, you end up with a mapping from a URL to a method invocation. That’s what the JRA does in a very simple way.

JAX-RS defines an object tree based on the resources and sub-resources specified by a path. Methods may return sub-resources on which further resource specification is invoked until you get to a terminal method. Did you get that? It’s very nice, academically. However unless you’ve been working with REST for a while and are really a dyed-in-the-wool believer, all that just gets in the way when you’re just trying to map a URL to code. I question the ability to make this fast as well, given the sub-resource concept. Not to mention that the spec itself says it does nothing to create client. I’m a believer that there should be a service interface shared on both the client and server: the server should implement it and the client should get a proxy facade using it. JRA lets you do that and JAX-RS doesn’t.

Anyway, this is probably a futile discussion as JAX-RS is being discussed for inclusion in the next JavaEE standard (!) and a lot of people are thus looking at it as the way to do REST on Java. I hope I’m wrong…