Restlet, a Java framework for building REST-ful applications, reached a new milestone this past week with the 1.1.0 release, the first major release since April of 2007.
The 1.1.0 release contains a number of significant changes, as detailed on the Noelios Technology weblog:
- Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation.
- Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo!
- One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach.
- New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser.
- New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies.
- Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available.
- New POP3 connector based on JavaMail to access RESTfully to remote mail boxes.
- New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance.
- New internal HTTP client and server connectors to simplify development phases (zero configuration necessary) and allow very small footprint deployments.
The Restlet framework is able to run from within any Java servlet container (via the RestletServlet), or as a standalone Java application, allowing for a number of deployment and configuration options.
The aforementioned NIO HTTP server connector shipping in Restlet 1.1 is provided for the standalone Java version of Restlet, and is based on the Grizzly NIO framework used in GlassFish.
JSR-311, which was released last month, defines the JAX-RS 1.0 specification. As defined above, Restlet supports this specification, and Jérome Louvel, the lead developer of Restlet, was part of the expert group for this JSR.
InfoQ had a chance to talk with the Restlet project lead, Jérôme Louvel, about the release. First, we asked about JSR 311 support:
We have been part of the JSR 311 Expert Group and were able to provide some significant feed-back to the specification leads. The Restlet API was also an important source of inspiration during this effort. With our long experience, being the first REST framework for Java (we publicly launched in the end of 2005), we were in a great position to offer support for JAX-RS to Restlet users.
Therefore, we are happy to announce the release of a very complete implementation of JAX-RS 1.0 (the API defined by the JSR 311) in our latest Restlet 1.1 version. This is the fruit of the hard work of Stephan Koops in the context of his Master Thesis. Stephan is also continuing the development of this implementation in collaboration with the Restlet community.
His next goal is to gain access to the TCK via the JCP scholarship program and get the JAX-RS extension for Restlet certified. But we are already quite happy about the current state of the implementation, which leverages many features from the Restlet API, like the availability of all our connectors (like Jetty, Grizzly and Simple) and of the Restlet services (like the conversion of URI file extensions into proper HTTP content negotiation headers).
Next, we asked when Jérôme would recommend to go with JAX-RS, when with the native Restlet API?
In order to make this choice, you need to look at several aspects.First, we have two radically different designs in hands. With the core Restlet API, we followed a traditional class-oriented design that will seem familiar to Servlet API developers. Basically, all significant REST and HTTP concepts have a corresponding Java class in the API, allowing a very intuitive mental mapping from the theory and the protocol to the Restlet features.
This results in a compact, reusable and extensible framework. For example, we are able to deploy our Restlet application into various environments such as Servlet containers, OSGi kernels, Spring and Guice IoC containers, standalone JVMs, Groovy, Scala or JAIN/SLEE. We have even ported our Restlet API to GWT 1.5 (Google Web Toolkit), allowing Web browsers to nicely interact with any RESTful back-ends, as opposed to using the default GWT-RPC solution. We are also planning to port our Restlet API to Google Android in our next 1.2 version!
JAX-RS on the other hand has followed a rather new annotation-oriented design. The idea is to start from domain objects (POJOs) and to annotate them to describe how they should expose a REST API. In theory, the same POJOs could also be annotated for JAXB in order to describe how they should serialize to XML or JSON.
However, in real REST applications, you quickly realize that it is not sufficient to annotate existing domain objects. REST implies a radically new way to think and design your Web applications: what we call the resource-oriented paradigm. There are some similarities with the object-oriented paradigm, but protective encapsulation is replaced by open representation of state, identification is based on URIs and the interface is unified (based on HTTP methods). Most importantly, the granularity is different between your resources in the REST layer and your supporting domain objects, requiring the definition of a new set of resource classes. Rather than annotate those resource classes, I think it is easier and more powerful to make them inherit from our base Restlet Resource class.Now, as a JCP approved standard, JAX-RS will sometimes become a requirement for new projects , especially as it will be part of the upcoming JEE 6 standard. Some companies will always feel more comfortable with JAX-RS API as it gives them a feeling of protection from vendor lock-in with the ability to port their code from one implementation of JAX-RS to another.
However, this has become much less important in the age of open source than it was in the age of proprietary software when JEE was first defined. Just look at how Spring, Hibernate or Groovy are changing the face of the Java world. Also, in practice, each vendor will tempt you to use features that are not available in the standard, like client-side support which isn’t part of JAX-RS 1.0, therefore reintroducing a level of vendor locking.Finally, the features scope of the Restlet API is much broader than the one of JAX-RS. We support both client-side and server-side applications and connectors for several protocols (HTTP, SMTP, POP3, FILE, JDBC, etc.) with clean mapping to HTTP semantics, all with a single unified API. We also provide a full alternative to the Servlet API, with more dynamic and flexible URI mappings, programmatic support for connectors, authentication and virtual hosts. The Restlet API also provides classes to serve directories of static files, with automatic content negotiation and remote update support. It also provides everything you need to setup a reverse proxy to provide access to external REST APIs from your sandboxed Web browser applications.
In the end, I would recommend using our JAX-RS if the support of JCP standards is required by your project or if you do prefer annotations as style of programming. In other cases, I would recommend to stick with our core Restlet API to get a more comprehensive and intuitive support of REST/HTTP and to keep more deployment options open.
Finally, we wanted to know more about the Restlet community:
There are eight committers working on the Restlet code base. Two are core committers funded by Noelios Technologies, the company driving the project. They take care of the Restlet core (API and engine) as well numerous extensions, the build process and the integration of the external contributions. We have counted about 160 contributors to the project since its initial release!
We also have six extension committers taking care of specific extensions like JAX-RS, GWT or XDB (Oracle). Those committers are either individuals or developers funded by other partner organizations like Solertium or the University of Manchester.
Most importantly, Restlet is a vibrant community of users and contributors, supporting each others and collectively driving the Restlet project in the direction that is the best suited for their project needs.
