How to choose between Jersey, Apache Wink and JBoss RESTEasy? [closed]

I just heard about Apache Wink, and I was wondering what differences it had compared to Jersey or JBoss RESTEasy. What can be done in one that the other two can't?

We've been using Jersey for some of our internal projects mostly for it's simplicity, but I can't really figure out what makes these other two any better that I would consider switching. Does anyone have any use-cases for which niche each of these fills?


Solution 1:

JAX-RS Implementations

Jersey

  • Reference Implementation
  • Usually the most cutting edge
  • Supports true asynchronous (ie web sockets etc...) connections through either Atmosphere or 2.0 version.
  • Has support for Spring and standard injection containers (ie @Inject).
  • Glassfish bundles it.
  • Its much more modular than the other JAX-RS projects.
  • It has a kick ass URI Builder
  • Does not necessarily require servlet container.
  • Grizzly support
  • Netty support (very early).
  • Swagger support
  • Sort of missing OAuth 2.0 . You'll have to use other libraries.
  • Some MVC support through Viewables
  • Hosted on java.net (a minus as the site is terribly slow at times).
  • Licensing is based on CCDL 1.1 and GPL-v2. Please make sure you check Jersey licensing before you use it for commercial use

https://jersey.github.io/license.html

RestEasy

  • Much of the above but most notable supports view technologies (see HTMLEasy)
  • It does have asynchronous connection support
  • Cache support
  • EJB support (if your into that crap)
  • JBoss bundles it (I think)
  • Netty support
  • Arguably the best Spring integration (MVC handler).
  • Early Swagger support
  • More security support including early OAuth 2.0 support

Apache Wink (never used it)

  • I have no idea why this project exists.
  • Supposedly its high performance focused.
  • It has a client built on top of HttpUrlConnection (which is a minus... it should be pluggable like Spring RestTemplate).
  • Basically Wink was developed in house at some enterprise companies and then given to Apache.
  • Requires a servlet container.

Restlet

  • Very powerful but very complicated
  • Provides some low-level REST support
  • Does not require a servlet container

Apache CXF

  • Some interesting WADL support.
  • Reuse and or combine JAX-RS w/ JAX-WS
  • Security support
  • Integration w/ Spring albeit kind of nasty
  • Supposed Autogeneration of client stubs

Other RPC-like systems

Message Queues

  • RabbitMQ
  • ActiveMQ

Asynchronous RPC

  • Finagle -- from Twitter.
  • msgpack-rpc

My humble opinion

I know the OP asked for REST but if this is for internal communication seriously consider using either a message queue or some other asynchronous RPC (Finagle) instead of traditional REST if your requirements match those systems.

If it must be classic HTTP REST (external) I would choose between either RestEasy or Jersey as a bulk of the mind share is put into those two projects.

Also see: Rest clients for Java?

Solution 2:

When choosing the implementation to use have this in mind: if you try to deploy a Jersey web service to JBOSS 7.1, it will not work. This error will occur:

Only one JAX-RS Application Class allowed

This is because REST Easy comes bundled with JBOSS as the default JAX-RS implementation. So, JBOSS will decide that that's the implementation you want to use and will not load another JAX-RS implementation (like Jersey). In order to fix this, you need to add the following lines to your web.xml file:

  <context-param>
   <param-name>resteasy.scan</param-name>
   <param-value>false</param-value>
  </context-param>
  <context-param> 
   <param-name>resteasy.scan.providers</param-name>
   <param-value>false</param-value>
  </context-param>
  <context-param>
   <param-name>resteasy.scan.resources</param-name>
   <param-value>false</param-value>
  </context-param>

Link: https://community.jboss.org/message/744530

Solution 3:

One of my favourite Jersey extensions is Viewables. Viewables allow you to bind your data easily to a JSP page to implement a true Model-View-Controller (MVC) architecture:

  • http://blogs.oracle.com/sandoz/entry/mvcj