75

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?

Nick Klauer
  • 5,893
  • 5
  • 42
  • 68

4 Answers4

114

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

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

Asynchronous 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?

cuihtlauac
  • 1,808
  • 2
  • 20
  • 39
Adam Gent
  • 47,843
  • 23
  • 153
  • 203
  • 1
    I don't recommend Jersey (I only tried v 2.5.1) one bit. It's extremely hard to configure and setup in the first place. – Muhammad Gelbana Feb 15 '14 at 12:27
  • Can you explain why Restlet is complicated from your point of view. Have a look at the first steps example: http://restlet.org/learn/guide/2.2/introduction/first-steps/first-server – Jerome Louvel May 10 '14 at 04:44
  • Perhaps "complicated" is not the right word and restlet also has evolved. I guess when I looked at restlet it seems to be way more stuff than jaxrs. It probably is the most comprehensive rest server library hence the "complicated". – Adam Gent May 11 '14 at 14:18
  • 2
    It does have a much broader REST/HTTP feature scope, 6 editions, 44 editions and been around since 2005, but its core org.restlet.jar is very compact (zero dependency), unified client and server. Have a look at our first steps example, to see how you can get started in 5 minutes without having to configure any Servlet container or XML config. But still, you can grow/scale very far: http://restlet.com/discover/firststeps – Jerome Louvel Jun 06 '14 at 04:11
16

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

Tihomir Meščić
  • 542
  • 7
  • 15
  • 6
    This is very useful information (although it answers a different question). – Rick-777 Jun 12 '14 at 10:22
  • My guess is (long time since I've worked with JBOSS stuff) is that you can exclude the provided JAX-RS in JBOSS. Or you can exclude it in your pom. Bottom line: this is a problem you can work around. – Johanneke Jun 07 '17 at 16:26
5

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:

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
bdoughan
  • 147,609
  • 23
  • 300
  • 400
1

If you're going to use JBoss 7.x you must use RestEasy, 'cause it's integrated in JBoss. To use Jersey with JBoss 7.x, you have to disable RestEasy and it is complicated!

Rick-777
  • 9,714
  • 5
  • 34
  • 50