JAX-RS Vendor Comparisons

I'd like to evaluate the four products that I know of that support JAX-RS:

• CXF - this Apache hosted project is a merger between XFire (a SOAP Framework) and Celtix (an Open Source ESB, sponsored by IONA)
• Jersey - the production ready, reference implementation from Sun
• RESTEasy - JBoss's JAX-RS project, from the mind of Angry Bill Burke. (I say that with great respect)
• Restlet - This project has been around for a long time and implemented REST before REST was popular. JAX-RS was a natural extension

I'm interested in comparing the following aspects of the JAX-RS implementations that extend beyond "pure" JAX-RS:

Maturity of the product - We need mature features and a mature and active user community are pretty important. We don't want to encounter too many problems, and when we do, we want to make sure that we can solve those problems quickly. JAX-RS is a standard API which is implemented using existing infrastructures. There will be plenty of "infrastructure" type hurdles along the way, so we'll be a lot more secure knowing that we're using a mature infrastructure

Server-side Integration Strategies - I have an existing Spring/Hibernate infrastructure and a strong familiarity developing on that infrastructure stack. Each product integrates with Spring, but there are different degrees of integration. There are also built-in integration with other development stacks, for example EJB.

Java Client API - There is no JAX-RS Client API, so each JAX-RS implementation has it's own take on how to perform Java-to-Remote-RESTful-Resource calls. There are pros and cons to each approach. Theoretically, we can have a client from one product call a service from another product. I need the ability to change all client calls by adding some query parameters (security and "time-machine" parameters to test different date scenarios). I also

Product Purpose - Jersey is meant as a reference implementation. RESTEasy is a playground for new ideas. CXF has an "enterprise version" supported by IONA. The Restlet project grew out of a desire to have a RESTful API alternative.

Of course there's more to it than those brief introductions, but the original purpose and current status of a projecct will play into vendor selection decisions.

Other Service Providing Models - The JAX-RS is a common API that can wrap an existing infrastructures, but a couple of the produts have APIs that predate JAX-RS and can be used in combination with JAX-RS development. For example, CXF (an ESB) provides plenty of transport mechanisms and exposes SOAP services via JAX-WS. Restlet's main RESTful API is not annotation based, and

Configurability - I need to solve problems like cross-domain issues and browser performance. I'd like the flexibility to wrap JSon in a method, return HTML fragments and return dynamically created JavaScript with document.writes. The method-wrapped JSon approach is used in combination with mapping extensions to mimeTypes. I can do more interesting things with extensible configuration options, as long as the extension points are exposed in a clear and simple way.

Security - "How do I secure my RESTful service?" is a pretty common question. JAX-RS does have a notion of a Security Context, but leaves a lot of the specifics to the implementation.

Performance - There are quite a few components to performance testing these containers, including representation-object binding speed, requests/some-time-frame metrics, memory consumption and the impact of adding a large number of services. I definitely won't have enough time to perform an exhaustive study on this... Perhaps this is a good topic for William Louth .

I'll give some background on what I need, to both expose my biases and my needs. We have a large website -- let's call it NationalPark.com. There is a large section devoted to functionality that's self contained and sufficiently different from the rest of the site -- let's call it RestArea. The functionality of RestArea is reused in a handful of deployments: a couple on NationalPark.com and a few other deployments on other sites. NationalPark.com and the other websites are all developed on the Spring/Hibernate stak. We are rethinking the underlying functionalty of RestArea, and want to enrich the user experience of RestArea. We also want to separate RestArea deployment from the rest of NationalPark.com so that problems in RestArea don't spill over into the rest of NationalPark.com. A SOA/SaaS model will give us all of those features, but will also let us have more deployment options across the rest of our websites... We can deploy RestArea into one manageable environment across all of our websites, or we can deploy RestArea once per unique function. Did I mention that there will be somewhere between a million and two million users of the RestArea across our websites?

I plan on doing more research on these aspects and I'll be posting some blog updates over the next few days. I posted an entry about Spring Integration. I'll follow it up with Client API comparisons next week. Eventually, all of this research can hopefully be used for a comprehensive comparison article.

Any input you have on comparing JAX-RS products would be greatly appreciated!

Originally posted on New York Java Consultant