InfoQ's Stefan Tilkov had a chance to talk to Jérome Louvel, lead developer of the Java Restlet framework, which has just released its 1.0 version. Topics covered include the reason for Restlet's existence, REST support in Java Web services frameworks and in Ruby on Rails, expectations for JSR 311 and Restlet's roadmap.
InfoQ: Can you give us a brief explanation about what Restlet is for?
Jérome Louvel (JL): Restlet is a lightweight REST framework for Java. It helps you build Web applications that blur the lines between Web sites and Web services by embracing REST, the architectural style of the Web. As every major REST concept has a corresponding Java class, the mental mapping between your RESTful Web design and your code is straightforward.
It is an open source project distributed either with a CDDL license or a GPL one (with a Classpath exception). The project consist of a Restlet API, a reference implementation (Noelios Restlet Engine) and a set of extensions.
InfoQ: Why did you feel it was necessary to create another framework - isn't the Servlet API "good enough"?
JL: The Servlet API was released in 1998 and its core design hasn't significantly changed since that time. It is one of the most successful Java EE APIs, but it suffers from several design flaws and limitations. For example, the mapping between the URI patterns and the handlers is limited and centralized in one configuration file. Also, it gives control of the socket streams directly to the application developer, preventing some IO optimizations by the Servlet containers like the full usage of NIO features. Finally it does not support HTTP features like caching, content negotiation and content compression very well, causing too much pain to developers and preventing them to focus on their application specific code.
Another major concern was the lack of a modern HTTP client API in the Java EE stack. The JDK's HttpURLConnection class is hard to use and leaves too much HTTP features unsupported like expressing client preferences for content negotiation.
Frequently, people were relying on third-party HTTP client APIs to workaround those limitations. Again, NIO can't be supported with HttpURLConnection.
In 2005, I saw an opportunity to go beyond all those limitations, and to design a fresh API in the light of the REST principles. For the first time, we have an API that unifies client-side and server-side Web applications, an API that fully supports NIO and an API that lets the developer programmatically control its container, connectors and deployed applications without having to constantly rely on XML descriptors.
InfoQ: What do you think about the REST support in other frameworks (such as Axis2 or CXF/XFire)?
JL: I think that this support is useful but very limited. The major issue I have is that those projects were designed to be WS-*/SOAP stack and don't fit well in the REST world which defines a whole new paradigm: Resource-oriented design as opposed to Remote Method Invocation.
Axis2 for example only supports GET and POST methods and requires the remote method to be passed as an URI parameter. This is clearly not allowed in REST and shouldn't even be labeled as RESTful.
XFire 1.2 doesn't support REST but has made public a project for mapping POJOs to RESTful Web services. It would be similar to the approach pursued by the recent JSR-311 which aims to standardize such mappings based on a set of annotations and helper classes.
InfoQ: You are a member of the JSR 311 expert group. What are your expectations for this JSR?
JL: I expect it to produce a good mapping between REST resources and POJO domain objects. I hope that we will be able to achieve what JPA did between RDBMS databases and POJOs. I except this annotation-centered API to be quite complimentary to the Restlet API which already has a class-centered API for mapping REST resources to POJOs.
I also think that this JSR is a great opportunity to reconcile the REST and the WS-* camp as those annotations could also be implemented by projects such as Axis2 and XFire.
InfoQ: Can you tell us something about a few projects that rely on Restlet?
JL: Several applications are already deployed in production within organizations of various sizes, including Overstock.com, an Internet leader for brand names at clearance prices. The Restlet project is also used as a support technology for various software architecture classes covering the REST architecture style, for example at University of California Irvine, or at the INSA Rouen engineering school.
We also eat our own dog food and run all our Web sites with our Restlet engine. Considering the amount of attacks by denial of service that we get, we are confident about our scalability. Recently, we even released a public benchmark demonstrating these performance qualities. We are at the same level as popular Servlet containers and expect to overperform them in our next release which will add a fully NIO-optimized connector based on Glassfish's Grizzly NIO framework.
InfoQ: How do you think Java compares to other languages with regards to building RESTful applications?
JL: Our experience with popular RESTful alternatives like Rails or Django lead us to think that the Java/Restlet alternative is proposing a better and more performant support for RESTful applications. Rails and Django were not designed with REST in mind, those concepts were only retrofitted later on. This results in more contrived code than with Restlets. Django for example doesn't natively support URI templates to map between URIs and resources. Rails, by forcing an unnatural mapping between RDBMS CRUD paradigm and REST/HTTP methods achieves an unsatisfactory result where you have to workaround many constraints or adapt your resource-oriented design to fit into Rails view of the world. Restlet on the other hand doesn't impose you any persistence technology and lets you freely define your resources, their representations and how they map to your domain objects or to your database.
InfoQ: Can you elaborate a little on your criticism of Rails in this regard? What's unnatural about its CRUD mapping in your opinion?
JL: Beside the GET and DELETE HTTP methods that map nicely to SQL SELECT and DELETE verbs, I find the usage by Rails of POST method for creation rather unfortunate. The best method for creation in REST is PUT which is also used for updates. The advantage of PUT over POST is that if the operation fails it can be safely repeated which isn't the case for POST.
Also, lists of resources are mapped based on the table name and the numerical row ID, which may not always be pratical. You don't want to lose control on your URIs which are part of the user interface of your application and an essential concept in REST. In Restlet we don't impose any constraint on your URIs and you are free to map your resources and representations using any persistence technology that you are familiar with (JPA annotated POJOs, raw JDBC calls, object databases, etc.).
Another minor criticism is that Rails encourages the usage of an awkward ";edit" suffix to access to an edition Web page for a resource. This is a bit misleading as REST discourages the specification of non uniform methods via URI parameters. Rather, they should use a separate Web form resource that the browser would GET and then POST or PUT to.
InfoQ: You seem to have invested quite some time into Restlet. How much is this a "hobby" project, and how much does your company expect commercial success from it?
JL: This project was definitely not a hobby since its inception. It was an answer to a need I felt when building another important private project. I believe in professional open source and hope that the professional services (support plans, consulting) that Noelios Consulting is offering will allow us to continue investing as much time as we did so far.
InfoQ: What is your road map after this first version?
JL: Beside the maintenance of the 1.0 branch with bug fixing releases, we will soon start an 1.1 branch. Some of the enhancements we have in mind are the support for WAR packaging (without the need for XML descriptors), the option to configure Restlet Components (containers of portable applications and virtual hosts) via an XML descriptor to facilitate the job of administrators. We also have several connector prototypes to complete, one HTTP server connector based on Grizzly NIO framework core that should bring us extra scalability and responsiveness, and two HTTP connectors based on JXTA virtual sockets (one client and one server).
We also want to continue deepening our support for HTTP with features such as content range, Digest and WSSE authentication. We also plan to submit the Restlet API to the JCP in 2008. It could be a good opportunity to deprecate and progressively retire the Servlet API.
InfoQ: Thanks a lot for your time!
Jérome Louvel is a software architect and the founder of Noelios Consulting. He has more than 8 years of experience in software edition and consulting, both in Europe and North America. He has a particular interest in Java, REST, the Semantic Web and Business Process Integration.
