- January 23, 2009

Restlet 1.2 is on its way with a first milestone! Let’s review the main changes made since version 1.1…

Security refactoring

The refactoring of the Restlet security model has been the most requested change since the Restlet 1.0 release. Fortunately, after a long maturation period, it has finally made a huge step forward, materialized by the addition of an “” package. The new design is the synthesis of many contributions and discussions from the community.

Therefore, I’d like to especially thank Bruno Harbulot, Stephan Koops, Rémi Dewitte, Raif S. Naffah, Rob Heittman, Roman Geus, Alex Horn and Rhett Sutphin for their precious help. We still have much work ahead to complete and fully implement the new design but there is now a good foundation for feed-back and contributions.

Packages restructuring

In order to simplify even more the learning and deployment of Restlet applications, the Restlet API and its implementation (ie. the Restlet Engine) have been merged into a single module (ie. JAR, bundle). All engine classes were moved to “org.restlet.engine“.

In addition, all extensions are now located under a “org.restlet.ext” root package. This means that all extensions previously under “com.noelios.restlet.ext” have been moved. Be careful as this will break existing applications relying on those packages. However, as all the classes are still present, the migration should be straightforward, especially if you use the auto-import feature of your IDE.

Note that the core Restlet API has not significantly changed itself, only a few extensions are affected and a couple of classes not typically used by Restlet application developers such as:

  • org.restlet.util.Engine moved to org.restlet.engine.Engine
  • org.restlet.util.Helper moved to org.restlet.engine.Helper
  • org.restlet.util.ByteUtils moved to
  • org.restlet.util.DateUtils moved to org.restlet.engine.util.DateUtils

Note also, that there were two Spring extensions in Restlet 1.1. Now they are merged under the “org.restlet.ext.spring” extension, led by Rhett Sutphin.


Connector enhancements

Thanks to a contribution of Kevin Conaway, the internal HTTP client now supports the HTTPS protocol as well, with parameters to configure SSL.

In addition, a Lucene extension has been created to host the Solr client connector contributed by Rémi Dewitte who will lead this extension. There is also a TikaRepresentation available to leverage Lucene Tika subproject when extracting metadata from representations.

Semantic Web initial support

As announced last August when we presented the Restlet 1.2 roadmap, we want to make Restlet a great framework to build applications for the Semantic Web. The relationship between REST and RDF is perfect and builds around the concept of resources and their representations (REST) and the expression of meaningful links between those resources (RDF).

We have written a detailed specification and gathered feed-back from the community and especially Henry Story, an expert in this area.

In Restlet 1.2 M1, we have added Literal, Link,  LinkReference, LinkSet and RdfRepresentation classes. That makes it easy to build a RDF graph, like you would use a DOM API to build and XML document. We now have to develop the serialization and deserialization logic during the next milestone for formats like RDF/XML and RDF/n3.

Direct contributors

  • Ben Johnson
  • Charles Gay
  • Cliff Binstock
  • Cliff Binstock
  • Daniel Woo
  • Eirik Bjorsnos
  • Frank Hellwig
  • John D. Mitchell
  • Jonas Maturana Larsen
  • Kevin Conaway
  • Nicolas Rinaudo
  • Remi Dewitte
  • Rob Heittman

Thanks for all others who helped us supporting the community in the discussion list!

Additonal resources

Changes log:

Download links:

Maven repositories: is updated on the 1st and 15th of each month is updated daily with new artifacts (access reserved to subscribers)

  • Xiaodong Qin

    Dear Jerome:

    I am working for Overstock on restful web services recently.

    We ran into a problem with the JAXB validation.
    The web service can pass an invalid object with missing attributes, the restlet framework does not seem to capture it.

    We do pass an implemented “ValidationEventHandler” object (with basic logging messages) to the JaxbRepresentation constructor, but the callbacks are never hit.

    I was wondering if you have any insights to the following questions:

    1. Is JAXB supposed to do the validation?

    2. If the “ValidationEventHandler” callbacks are not hit, does
    it mean it is a restlet bug, or there is something we need to
    do to turn on the JAXB validation within restlet?

    When and how do the callbacks from restlet get called?

    3. I believe JAXB validation can be done on either marshalling
    on client side, or unmashalling on server side, what might
    be the potential performance cost if we are able to turn
    on the validation somehow?

    4. What is preferred, client side or server side validation?
    I believe server side validation should be turned on anyway,
    validation is always crucial to ensure the integrity of the
    incoming data.

    Look forward to your reply.



  • Hi Xiaodong,

    Restlet 1.2 M1 is your answer! It incorporates enhancements to the base XmlRepresentation class which now has a “validating” boolean property to configure XSD/DTD validation.

    Let me know if it works better for you! The best is to continue this discussion in our mailing list at: