jump to navigation

“Restlet in Action” book progressing in MEAP March 3, 2011

Posted by Jerome Louvel in Ecosystem, Noelios, Restlet General.
1 comment so far


When we launched our “Restlet in Action” book project via the Manning Early Access Program (MEAP), we knew we had a long road ahead. This effort has been a source of intense work, an opportunity to step back, take the user seat and exchange in new ways with our community. For example, we have already been through two external reviews and had very regular discussions with readers in the book forum.

The book is now expected to go for printing during Summer 2011, synchronized with the release of Restlet Framework 2.1.0 version. Note that the book will cover both 2.0 and 2.1 versions of Restlet.

Recently, we have published the first two parts of the book, including the first 8 chapters in a total of 12. As it stands, the book already provides very valuable information for both Restlet newcomers and more experienced developers. In addition to presenting the technology we also provide guidance on how to design a RESTful web API, a very hot topic nowadays.


Our immediate priority is to write chapter 9 and finish the edition of chapter 10 in order to release them on MEAP in the coming weeks. Like chapter 7 on security which was contributed by Bruno Harbulot, those two new chapters covering Restlet usage with browsers, mobile devices and cloud platforms are being contributed by Thierry Templier, an experienced writer and engineer that will join our company, Noelios Technologies, next month (welcome to Thierry the Second!).

Over the past weeks, a second review of the manuscript was completed thanks to the help of about 10 external reviewers. We received very detailed feed-back, with many suggestions for improvements and corrections. As a result, we have established a thorough action plan containing about 50 action items that we intend to address. We have also addressed the easier comments on the fly by fixing the manuscript like we generally do with feed-back received via this book forum.

The next priority will be to work on this action plan and in parallel write the two other remaining chapters on  “Embracing the Semantic Web” and “Looking beyond this book”. Finally, Manning will launch the printing process, including precise copy edition to improve the English prose and the general writing flow (we are not native English writers!). Thanks for your interest and support, we are almost there!

Special offer from Manning:

  • Save 40% off the book price

GSoC and Restlet integration with Equinox May 6, 2010

Posted by Jerome Louvel in Ecosystem, Equinox, GSoC, OSGi, Restlet General.
1 comment so far

Two years ago, we announced that NASA launched Restlet on the OSGi orbit by developing an integration of Restlet 1.1 with OSGi, based on Equinox extension points. This effort was presented at EclipseCon 2008 & 2009, and the code was contributed to the Ensemble project under a special license as explained by Bryan Hunt in this post. Also, listening to feed-back on OSGi from Restlet community, version 2.0 of the Restlet Framework was enhanced to ensure that all its modules and dependencies were available as good OSGi bundles.

However, even though deploying Restlet components and applications in an OSGi environment is already possible and explained in the user guide, it doesn’t take advantage of the dynamic and extensible nature of OSGi. Today, Bryan Hunt pointed me to a great tutorial written by Wolfgang Werner that nicely describes the Restlet Framework, covers its usage with Eclipse’s Plugin Development Environment (PDE) and explains how to leverage Equinox’s extension points to dynamically register Restlet components, applications and resources. See the series of posts titled “Building web services on Equinox and Restlet”:  part #1, part #2 and part #3.

But wait, there is more good news as a Google Summer of Code 2010 project “Restlet integration with Equinox” was proposed by the Eclipse Foundation and just accepted by Google! Thanks to Bryan Hunt for initiating the effort, to Equinox’s development team for supporting it, including Jeff McAffer, Simon Kaegi and Scott Lewis. We also received a positive review from Benjamin Cabé, an Eclipse contributor. Thanks also to all supporters including Jeff Norris and Khawaja S Shams from NASA, Rob Heittman from Solertium and Thierry Templier.

Two students proposals were submitted, one from Rajeev Sampath and another one from Samrat Dhillon. The first one was finally selected but Samrat has offered to contribute to the project. Rajeev is a Computer Science undergraduate student from University of Moratuwa, Sri Lanka, with good Java and distributed system experience as illustrated by his participation to the Epzilla project on Complex Event Processing (CEP).

I’m very happy to see this project, initiated by the Restlet community, taking shape and wish it full success. At Noelios Technologies, we will support it as co-mentor and encourage other interested parties to join and contribute. The project web site at Google Code is here… stay tuned!


Restlet, a RESTful middleware for GWT, GAE and Android December 17, 2009

Posted by Jerome Louvel in Android, Ecosystem, GAE, Google, GWT, Microsoft, REST, Restlet, Restlet General.

The Web is taking multiple shapes with the Mobile Web, Cloud Computing and RIA being hot topics recently. If you follow this blog frequently, you are certainly aware that the Restlet Framework, the first RESTful web framework for Java developers, is available in five consistent editions since version 2.0 M4. Each edition targets a special development environment:

  • Google Web Toolkit (GWT) for AJAX applications deployed in desktop browsers, without any plugin required
  • Google App Engine (GAE/J) for deployment on Google’s cloud computing infrastructure
  • Android for deployment on compatible smartphones
  • Java SE for standalone deployments in regular Java Virtual Machines
  • Java EE for deployment in Servlet engines

Each edition is offering the same Restlet Framework, with restrictions and adjustments based on the target environment. For example, the GWT edition only supports the client-side usage of Restlet, while the GAE edition only provides compatible extensions and ensures that we don’t break the security sandbox or use unsupported JRE classes.

As a result, you can easily develop a unified Restlet application with a server-side deployed in GAE, a client version available for Android smartphones and another available for desktop browsers with GWT, fully leveraging the most innovative technologies available from Google for Java developers.

You might wonder what exact value does Restlet brings in the middle of those technologies? The Restlet Framework is all about REST, supporting advanced HTTP features such as content negotiation, caching and conditional processing, allowing for the same URI-addressable resource to expose various representations. Each representation renders the same information in  various languages or formats such as JSON, XML or anything else that makes sense for your clients such as binary pictures.

Supporting content negotiation allows your Restlet cloud server to expose the same resources to all its clients, including an Android smartphone client, a GWT desktop client, a Flex client, a programmatic Java SE robot or a basic HTML browser. One Java API and one unified code base gets you covered in all those scenarios, even if you need to serve static files: a Restlet Application truly merges the notion of Web Site, Web App and Web Service!

So, using Restlet as a cloud server gets you much further than a regular Servlet application. Usually, you would use GWT-RPC to communicate between your GWT client and your GAE back-end, and the low-level HTTP client provided by Android to communicate with your GAE custom Servlets. Obviously, the result wouldn’t be very RESTful as GWT-RPC is introducing some strong coupling. You could use the low-level HTTP client provided by GWT as well, but then you would loose the big benefit of using Java proxies in GWT, with transparent serialization of parameters and result object.

This is where the Restlet Framework comes to rescue! For GWT, we provide both a high-level HTTP client, removing the need to manually parse and format HTTP headers thanks to its Restlet API but also a proxy generation mechanism based on GWT deferred binding very similar to GWT-RPC but truly RESTful! Migration of existing GWT-RPC code is straightforward as we also support GWT-RPC AsyncCallback interface in addition to our equivalent Result interface. For our serialization format, we reused the one of GWT-RPC, a special JSON variant, therefore it is fully featured and as robust as GWT-RPC ! In your Restlet cloud server, you just need to add our server-side GWT extension to transparently support this serialization format, thanks to content negotiation.

If you are a Google fan, you should be happily developing with the recent GWT 2.0, Android 2.0 and GAE 1.3.0 releases and the RESTful solution described above should gives you a big smile and to get started, we have written a complete tutorial, with full source code, illustrating a unified Restlet application for GAE, GWT and Android.

But even in this scenario, you wouldn’t be restricted to Google technologies, you could chose to support alternative clients such as regular HTML browsers, Flex or Silverlight clients, or any other HTTP client. On the server-side, you could take the same Restlet application and deploy it locally, or on Amazon EC2 or Microsoft Azure, thanks to our Restlet editions for Java SE and Java EE which can be installed on those major cloud platforms!

In the end, the Restlet Framework offers you, for free, the first comprehensive RESTful middleware for Google technologies and beyond! As a last word, I would like to thank again my friend Didier Girard, for sharing his insights that led us to this post (and a lot of work!) 🙂

Towards RESTful Web Content Management December 10, 2009

Posted by Jerome Louvel in CMS, Ecosystem, REST, Restlet, Restlet General.
add a comment

The Restlet community is so diverse that it is difficult to cover all related projects and products. Sometimes, it is easier to identify trends and connections. Like for most sectors of the software industry, the Web is exerting a lot of attraction on Content Management Systems (CMS), including Enterprise Content Management  (ECM) and Document Management Systems (DMS).

As a result, those products typically offer a mechanism to programmatically interact with their CMS through the Web, by providing a Web Service API. Ideally, those APIs are designed RESTfully such as Nuxeo ECM which leveraged Restlet. This approach was explained in more depth in a CMSWire article covering Alfresco’s RESTful approach and mentioning Restlet has a good candidate for lighter and more RESTful Web frameworks.

Jalios JCMS, a commercial ECM product, also leverages Restlet for their RESTful OpenAPI. Another nice example of a REST API based on Restlet was recently provided by NeoDoc in their Calenco product, a CMS focusing on the collaborative edition of documents such as strategic business documents, technical documentation, user guides, quality manuals or security procedures.

While each of those REST APIs supports the special features of their related CMS, users might prefer for some scenarios to use a more generic REST API, not tightened to a particular vendor or project. This is the purpose of the Content Management Interoperability Services (CMIS) standardization effort. Version 1.0 is currently is final review stages, and seems to be gaining a lot of traction.

However, Roy T. Fielding expressed some critics on the initial draft in this blog post, pointing to its lack of RESTfulness and the fact that it was too focused on document management instead of content management as its name implies. It seems that the RESTfulness concerns were mostly addressed, but not the one of the scope of the specification . Note that Nuxeo already supports CMIS and that Jalios has planned its support as well.

Finally, there is a new trend in CMS called Web Content Management (WCM), focusing on the online edition of Web documents and Web sites in general. This family includes Wiki software like the powerful and open source XWiki which also leverages Restlet for their REST API.

Another illustration of this trend leading to more and more convergence of CMS towards the Web are major online services like Google Docs and Microsoft OfficeLive, enabling the collaborative edition of enterprise content, progressively blurring the line with regular Web content. As a final illustration of how Restlet can successfully support the development of WCM systems, I recommend you to have a look at GoGoEgo, a very promising open source RESTful WCM recently launched by Solertium.

Their solution not only provides a REST API, but is fully designed as a RESTful Web application, with an administrative front-end based on GWT and the ability to be hosted on the cloud with Google AppEngine. Solertium is also a strong supporter and contributor to the Restlet project, as illustrated in this passionate post from their CTO about friendly frameworks!

Update : Mentionned CMIS implementors. Adjusted wording regarding Roy & CMIS based on feed-back from Benoît Dissert of Jalios

Microsoft selects Restlet to show REST interoperability February 20, 2009

Posted by Jerome Louvel in Ecosystem, Microsoft, Noelios, REST, Restlet, Restlet General, User interface.

After a long investment in WS-*/SOAP initiatives, Microsoft has recognized the value of REST. But they didn’t adopt REST only on the surface, they have put in place a comprehensive offer and are actively working to demonstrate and facilitate the interoperability with other platforms such as Java.


Facing a strong competition in the Rich Internet Application area, from Google with GWT, from Adobe with Flex/AIR/Flash and more recently from Sun with JavaFX/Applets, Microsoft has finally reacted with the introduction of their Silverlight 2 technology.

Silverlight requires a browser plug-in (ActiveX available for IE, Firefox and Safari) and provides you with a subset of the .NET Framework. Microsoft supports Windows and Mac while Novell has a Linux version called Moonlight. For the user interface it relies on a declarative language called XAML, not too different from Flex MXML or JavaFX scripts.


Regarding communication, it relies on WCF and offers direct support for HTTP/REST, RSS and Atom, POX/JSON and XML/LINQ. A description of the full architecture is available here.

Now, if you follow this blog, you are probably wondering how Silverlight interoperates with Java on the server-side. Even if its support for HTTP has a few limitations (partially due to its nature of browser plugin), Silverlight allows you to communicate easily with a REST back-end.

To demonstrates this, Microsoft has leveraged our Restlet framework and illustrated this interoperability with several detailled posts in their Silverlight plus Java blog written by Stève Sfartz from Microsoft. Other examples are available on Blog in the Cloud and Cloud it up.


If you are a traditional Microsoft developer, you would naturally turn to Visual Studio to develop your Silverlight applications, but what if you are a Java developer?

Well, Microsoft has done an unusual move by supporting the development of a Silverlight IDE for Eclipse! It’s called eclipse4SL and is co-developped with Soyatec, a French software editor specialized in Eclipse products development.


REST interoperability is also covered in eclipse4SL’s user documentation, illustrated by the usage of Restlet on the server-side. See this page for Restlet guidance. This is currently based on Restlet 1.0 and a Tomcat deployment, but work is underway to upgrade to Restlet 1.1.

The eclipse4SL project has even been submitted to the Eclipse foundation. See this post from the executive director of the Eclipse foundation.


After meeting with Stève Sfartz, who very enthusiastically introduced us to Microsoft projects for REST, cloud computing and RIA, we worked on a join presentation for the Microsoft TechDays in Paris.

The goal was to present interoperability scenarios around REST. Thierry Boileau did the presentation for Noelios Technologies. A detailled summary (in French) has been posted by Stève Sfartz on his blog.


This presentation gave us the opportunity to show case our recent support for the Shared Key HTTP authentication scheme. This protocol is similar to the one defined for Amazon S3 and allows you to access to Microsoft Azure Data Services from a Restlet Java client.

This new feature is available in recent snapshots of our future Restlet 1.2 release!

Update 1:  article from BetaNews covering Eclipse4SL and mentioning Restlet

Update 2: Stève Sfartz has posted a complete article on MSDN detailling the example showcased at the TechDays (in French), including downloadable source code.

Kauri, a holistic Web framework April 7, 2008

Posted by Jerome Louvel in Ecosystem, Restlet General.
1 comment so far

Last week, we met Outerthought, the creators of Daisy CMS. We use Daisy to run our Restlet community wiki and we found it very powerful and flexible. For example, there is an integrated book publishing feature, with table of contents edition, clean PDF and HTML generation and complete user management.

Outerthought has also been a very active Restlet contributor recently and they are now working on a new Web framework called Kauri. What is new with Kauri is the desire to address the needs of all the team members involved in Web application development and provide them an integrated solution, from the front-end to the back-end. This project also has a strong focus on REST and modularity and is built on top of other open source projects including Restlet, jQuery and Spring.

We spent a great day meeting Steven Noels, Marc Portier and Bruno Dumon in their nice and modern offices located near Gent (Belgium), introducing each others, sharing our views on open source business development and discussing technical aspects related to Restlet and Kauri. Steven has written a nice blog report on this day.