Which REST API do you prefer - Jersey or Restlet? This would encompass both the client and server API-s.
We really need to just pick one and kick the tires around but I was curious what the community thinks.
Restlet seems simpler and better documented to me. I've had a hard time even finding decent documentation about the Jersey client API.
Since this is a subjective question, I have a subjective answer.
I prefer to write the code myself and not use any framework to do the work for me. Why? My opinion is that you should write your own web service so that you completely understand how it works rather than letting some framework do all of the work for you which results in the you, the developer, not really knowing what the code is doing.
Once I had written a REST web service or two from scratch and knew how everything worked I tried to use the frameworks but I found them to be bloated and included many things I had no need of.
Don't forget good 'ole Spring too. They have plenty of pieces that support REST - the easiest being a normal Spring Controller that simple implements all the standard Http verbs.
A RESTful framework such as Restlet does not just provide handling of HTTP calls, otherwise the Servlet API would be sufficient. The idea is to support advanced features of HTTP such as content negotiation, conditional processing, caching out of the box and to provide a canvas for a RESTful design of your Web applications based on Resources, URIs and Representations. See a more complete list of features here: http://www.restlet.org/about/features
Also, Restlet isn't bloated and can be used either as a library or as a framework: it isn't unecessarily intrusive. Its core is a standalone JAR of about 500 Kb (no dependency beside Java SE 5.0), containing the Restlet API and engine, plus default client and server connectors for HTTP or local files. It can replace an HTTP server such as Apache HTTPd with static file serving and a complete RESTful security API. All other features are provided as optional extensions.
To get started, see the first steps example: http://www.restlet.org/documentation/2.0/firstSteps
Best regards,
Jerome Louvel
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
You might want to consider NetKernel 4.
It is a REST software platform that is written in Java, runs on the Java VM and supports languages that compile to or run on the JVM (Scala, Ruby, Python, JavaScript, XQuery, XSLT, etc.).
Since it is a REST software platform, the mapping from external REST web services to internal endpoint implementations is straight forward.
NetKernel can be run as its own platform or it can be instantiated as a POJO run embedded in any Java program or container.
I'm a big fan of Restlet. At my firm we've successfully used both the server and client APIs extensively in multiple apps, which have performed well and been stable for the long term.
I've also been extremely satisfied with how well-run the project is, with a clear roadmap; an open, flexible, and effective development process; a solid community; and an emphasis on stability and strong support of current releases.
I haven't used Jersey so I can't really speak to it.
Also, it may be useful to point out that while Jersey itself has it's own API, that's not the API generally used for developing RESTful applications with Jersey. As stated on its home page, Jersey is the reference implementation of the JAX-RS API, which the upcoming Restlet 2.0 also implements.
Therefore, instead of choosing between Restlet and Jersey, a good choice might be to develop an application using the JAX-RS API. Your code would then be implementation-agnostic, and you could choose an implementation for actually running your application based on the deployment, support, and other runtime characteristics of the two implementations.
Again, I'm not all that familiar with Jersey, but I've been very pleased with the flexibility of Restlet. Restlet supports RESTful web services running as a standalone application, or inside a standard Servlet container. It's many extensions, and the ability to make your own, also enable it to integrate easily into an organization's existing software ecosystem.
Good luck!
I have used Jersey and am happy with it, but I am considering converting to the spring implementation because I have had issues with the Jersey/Spring integration, mainly with AOP.
I've built a project with RESTlet. Recently I've begun evaluating Jersey. Jersey is close enough to what I want to continue trying it. The prior project may keep RESTlet out of inertia, but had I to choose all over again I would go with Jersey or rolling my own.
Where I work I selected RESTlet when building our first Java RESTful web service. RESTlet got the job done, but I found it it to be heavyweight and suffer from NIH.
Subsequently I prepared a hands-on workshop for my local JUG where I used Jersey. This wasn't enough experience to definitively say that it's better than RESTlet. However, my first impressions of Jersey are better than they were of RESTlet.
With a name like RESTlet, the project could have gone a couple ways:
The RESTlet creators believed the latter was the better choice. A consequence of this decision is that all the code inventing a new web app framework contributes to a large codebase, more dependencies, and more to understand when using RESTlet to build your service.
RESTlet does provide a Servlet. It's a bridge class that jettisons the Servlet API as quickly as possible.
If you think the Java Swing API is a great example of how to make a rich API then you probably disagree that this is a drawback for RESTlet. My bias is for less framework, less abstraction and less generality in a REST framework. Or at least an easier to use facade on top of your richly decomposed OO interface. Getting the value of query param called limit should not require this much code:
request.getResourceRef().getQueryAsForm().getFirstValue("limit")
Getting the value of URI template param is more straightforward. But the code above is symptomatic of a framework that reinvents instead of augments existing web frameworks.
A couple of the benefits of REST are simplicity when compared with other architectural styles and that REST services work with the grain of the Web. Similarly a REST framework should be simple and should build on the prior art for building web apps in Java.
RESTlet fails on both marks.
Based on initial experience, Jersey scores better on simplicity. If JAX-RS succeeds as a standard, then by definition Jersey works within the grain of Java web apps. Even without that Jersey feels a bit more natural. Annotations are a good fit.
I've used Jersey daily for 18 months and consider it to be the best news in Java web service development in the last few years. It's clean, works, and is a joy to program.