Enterprise Integration Zone is brought to you in partnership with:

I'm Solomon Duskis, NYC consultant and a Java/J2EE guy. I work at Sungard Consulting Services in NYC. The postings on this site are my own and do not necessarily represent the positions, strategies or opinions of my employer. Solomon is a DZone MVB and is not an employee of DZone and has posted 22 posts at DZone. You can read more from them at their website. View Full User Profile

JAX-RS Vendor Comparisons

09.26.2008
| 20373 views |
  • submit to reddit

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

Published at DZone with permission of Solomon Duskis, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Otengi Miloskov replied on Tue, 2008/09/30 - 5:23am

@Solomon: Thanks for your answer.

I follow your advice and it was a snap to use Jersey, I set up very quickly a helloworld service with  maven. I didn't need to do nothing descriptors or configurations just a few annotations and Java POJO code and thats all, It is awesome. This is really what I need. I used GrizzlyWebContainer embedded for test the client and I will continue to play around with it and try to integrate it with EJB3 and then I will try next Bill Burke offer RESTEasy. The other solutions also looks interesting, I will give a shot all of them :-)

Cheers

johnny resting replied on Thu, 2009/08/13 - 6:06am

Hi

I really like to see the next chapter of this article.

There is also a new stack in town, Apache Wink, that worth adding to this comparison.

Johnny

Amar Bhosale replied on Thu, 2011/08/04 - 6:54am

Hi Solomon, Do you have a latest comparisons for these REST frameworks considering the new versions of those frameworks ? What is best for RESTfull web services Jersey or RestLet? ~ Amar

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.