jump to navigation

Restlet improves OSGi support: new edition and update site November 9, 2011

Posted by Jerome Louvel in Eclipse, Equinox, OSGi, Restlet, Restlet General.
add a comment

While OSGi has been for a long time an important deployment environment for Restlet developers, including an innovative project lead by NASA JPL, we have seen a surge of interest in the recent years.

The rise of REST, the addition of an Eclipse Public License option to Restlet and an increased effort from Restlet community is starting to bring new fruits!

Edition for OSGi Environments

Since version 1.1, Restlet has always tried to be friendly to OSGi developers by ensuring that each Restlet module distributed as a JAR file was also a valid OSGi bundle, including correct manifest information.

We also ensured that dependent libraries were distributed as bundles as part of the various Restlet editions and distributions (Zip and Windows installer).

In practice, OSGi development isn’t supported on platforms such as Android, GAE and GWT, leaving the developer free to choose from either the Java SE or Java EE editions of Restlet, as both contain different extensions usable in OSGi such as the Servlet and Jetty extensions.

Progressively, we realized that a new edition of Restlet dedicated to OSGi environments such as Equinox and Felix was necessary to clarify the situation and make space for more OSGi specific features.

Using our automated Restlet Forge, we were able to deliver this new edition, including dedicated Javadocs and distributions as illustrated above.

Eclipse Update Site

In addition, we worked hard on providing a new distribution channel specific to this OSGi edition : an Eclipse Update Site supporting easy installation and automated update right from Eclipse.

Note that this is only recommended if you intended to develop OSGi applications leveraging Restlet, not applications for other target environments such as Java EE or GAE. In the later cases, you should either manually copy the JAR files in your Eclipse project or rely on our Maven repository using a tool such as m2eclipse.

In order to use the Eclipse update site, you should simply use this URL: http://p2.restlet.org/2.1/

More detailed instructions about using this update site are available on this page.

Restlet integration with ECF

In addition, thanks to the work of Scott Lewis, the Eclipse Communications Framework lead, an integration of Restlet with ECF is now available.

This integration supports the OSGi Remote Services specification by adding REST/HTTP bindings based on Restlet and leveraging the Restlet extension for OSGi introduced below.

For additional details, you can read his blog posts #1 and #2. Scott was also very helpful by providing regular feed-back on all others aspect of this blog post.

Upcoming Restlet extension

Finally, based on work initiated via a Google Summer of Code project in 2010, a Restlet extension for OSGi is entering in the Restlet Incubator with the goal to become part of the 2.2 version of the framework.

The extension facilitates the development of very dynamic Restlet applications, supporting for example the live addition of resources and virtual hosts.

This org.restlet.ext.osgi extension is lead by Bryan Hunt and has received significant contributions from Wolfgang Werner.


Step after step, Restlet support for OSGi and the Eclipse ecosystem is growing and we will continue to work in this direction, with plans to add visual tooling for Restlet in Eclipse and to provide more integration with OSGi standard services such as the log service. As always, stay tuned!


Restlet Framework 2.1 RC1 and 2.0.10 released October 7, 2011

Posted by Jerome Louvel in GAE, RDF, Restlet Releases, Security.
add a comment

Here is the first Release Candidate of 2.1 which freezes the features scope and the public Restlet API. It also marks the beginning of a stabilization and optimization phase.

In order to reach 2.1.0 early next year, we want to fix as many issues reported in our tracked as possible and welcome any help on this front, especially reproducible test cases and patches.

We will also complete the Restlet in Action book, which has already 10 chapters out of 11 written and most appendices ready as well. Manning should be sending a MEAP update emails very soon now, taking into account great feed-back from readers and technical reviewers.

In the coming weeks, we will also start working on version 2.2, but we will come back on this exciting topic in another blog post !

Bug fixed

First, the 2.0.10 version fixes 11 issues on the stable branch including:

  • HTTP DIGEST signature issues when targeting several URIs
  • Web form empty issue on the GAE edition
  • RDF writing issue with XML and n3 formats

Major changes

In addition, version 2.1 RC 1 contains several major enhancements and new features summarized below.

  • Added ChallengeScheme.HTTP_AWS_QUERY constant to Crypto extension with client-side support for Amazon Web Services special authentication scheme (using URI query parameters)
  • Better handling of special URI characters when encoding and decoding to workaround JDK’s URLEncoder/Decoder limitations
  • Added syntactic sugar to the RDF extension
  • Added ClientResource#addQueryParameter and addSegment methods
  • Added ClientInfo#certificates and cipherSuite properties
  • Added Authenticator#multiAuthenticating to better control optional authenticators and prevent several authentications if not necessary.
  • Updated all Apache libraries to recent versions
  • Updated Jackson to version 1.9.0
  • Updated FreeMarker to version 2.3.18 (security fix!)


Recent contributors

  • Alex Milowski
  • Arjohn Kampman
  • Avi FlaxBjorn Roche
  • Bryan Hunt
  • Cyril Lakech
  • George Calm
  • Henry Story
  • Matt Stromske
  • Raif S. Naffah
  • Sebastien Schneider
  • Steve Ferris
  • Warren Janssens

Thanks to all others who helped us in various ways for this milestone.

Additional resources

Changes log:

Download links:

Maven repositories:

Can the rise of SPDY threaten HTTP? October 6, 2011

Posted by Jerome Louvel in General, REST, Restlet, Restlet General.


The announce of Amazon’s Kindle Fire tablet last week was not yet another tablet launch in this already crowded market. This tablet came with a new way of browsing the Web using limited mobile devices, leveraging the power of the cloud in term of network connectivity, processing power and storage capabilities.

The most exciting part of Kindle Fire isn’t its hardware but its Silk browser and the cloud browsing infrastructure it leverages to achieve what they call split browsing.

This radical change in the way we might browse the mobile Web tomorrow, is the result of combining the traditional caching Web proxies used in large organizations to save their bandwidth, with the capabilities of Amazon cloud infrastructure.

The goal is to provide a faster browsing experience by adjusting web content (such as scaling down images) to the capabilities of the devices and offering better network latency thanks Amazon data centers connectivity and caching capabilities (think about using AWS S3 and CloudFront).

The final radical change that they made and which triggered this blog post, is the usage by the Silk browser of the SPDY protocol created by Google as a potential replacement for HTTP, already supported in the Chrome browser.

Can this become the beginning of the end of HTTP ?

HTTP history so far…

As you know, HyperText Transfer Protocol was early on a key stone in the Web building. It started as notes written by Tim Berners Lee in 1991. After an IETF standardization effort, the first standard HTTP/1.0 version (RFC 1945) was published by Tim Berners Lee, Roy T. Fielding and Henrik Frystyk in 1996.

With the exponential growth of the Web, it became quickly urgent to improve this protocol and address  scalability, performance and interoperability issues observed in the field.

This led to the definition of HTTP/1.1 (RFC 2616), and the formalization of REST, the architecture style of the Web, with major contributions made by Roy T. Fielding.

The version 1.1 of HTTP is now used by the vast majority of web sites, web APIs and web clients today, but there are still questions regarding the interpretation of its now aging and monolithic specification.

In 2007, an IETF working group was launch to revise HTTP/1.1 and address those issues, but without actually changing the protocol.

Refactoring with HTTP/1.1 bis

This HTTP/1.1 bis initiative led by Mark Nottingham and involving Julian Resche, Roy Fielding, Yves Lafon and a few others is now well advanced and we can hope this work to be complete soon, maybe next year. This rewrite of RFC 2616 splits the specification in 7 parts as illustrated below.

Parts of the HTTP 1.1 bis specifications

At the bottom, we find the Messaging part which deals with the HTTP connections management, raw message syntax and HTTP(S) URI schemes.

The layers above describe the semantics of HTTP and the major features offered such as caching, authentication, conditional requests and ranged requests. Those layers are exactly what the Restlet API exposes using Java as detailed in this mapping table.

The timing is perfect because pressure to bypass the limitations, real or perceived, of HTTP/1.1 is increasing.

The rise of alternatives

To overcome limitations of HTTP, especially for near real-time client updates, techniques such as Comet have emerged, pushing HTTP into its limits.


To overcome those limits, the HTML 5 WG has initiated a new WebSocket protocol that allows bidirectional exchanges between a browser and a server, only using HTTP for the initial handshake.

This protocol has been taken over at IETF in a bidirectional or server-initiated HTTP working group but it is unlikely at this point that this protocol will attempt to respect REST constraints (see this blog post).

Server-Sent Events

This is really the signal that those shortcomings of HTTP need to be addressed in a better way. One simple yet promising alternative is the W3C”s led Server-Sent Event specifications which cleanly leverage HTTP and JavaScript by proposing a special event-oriented media type.

The problem with all those techniques and new protocols is that they require your browser to open and maintain several HTTP connections to the same remote server, increasing the scalability issues.

Even if usage of non-blocking IO can help deal with those issues (as supported by the Restlet Framework), this makes things more complex than they should be, at least from a network TCP/IP point of view.


This is were the SPDY protocol offers an innovative solution by multiplexing several HTTP streams over a single connections. Those streams can go in both directions and be initiated by either the client or the server side.

In addition, SPDY proposes an alternative messaging layer to HTTP/1.1 but intents to stay compatible with all other HTTP layers above as described by HTTP/1.1 bis!

As illustrated in the previous figure, it is even possible to emulate the WebSocket’s JavaScript API on top of SPDY as available using a special option in the Chrome browser.


Better than a threat, SPDY design qualities and its growing support and usage by key players such as Google and Amazon is probably more a chance HTTP to see a version 2.0 defined and getting enough interest to succeed.

This new version could replace the existing messaging part of HTTP/1.1 by a fully multiplexed and compact alternative based on SPDY (see Wikipedia page) and other alternatives such as Roy T. Fielding’s own Waka or HTTP-MPLEX.

If you think this is just a wishful dream and that things so fundamental to the Web can’t change … then read this blog post from Mark Nottingham about SPDY (ex-FLIP) written back in 2009 and talking about a potential HTTP/2.0.

For sure, we are going to experiment with SPDY in next 2.2 version of the Restlet Framework and explore the future of HTTP!

Restlet Framework 2.1 M6 and 2.0.9 released August 20, 2011

Posted by Jerome Louvel in GWT, NIO, OData, Restlet Releases.
add a comment

We are still on track for the 2.1 RC1 release in September, but so many enhancements and bug fixes were added since 2.1 M5 that we thought it would be useful to many users to have this intermediary milestone.

Bug fixed

First, the 2.0.9 version fixes 10 issues on the stable branch including:

  • Inappropriate warning message about child contexts
  • IO flushing issue that could create troubles with writer based representations such as JsonRepresentation
  • Conversion of representations to instances of primitive type using the default converter
  • Handling of binary data in OData extension
  • Default converter took precedence over specialized converters when converting incoming representations
  • Lack of warning message when an unexpected error happen during the invocation of an asynchronous callback

Those fixes are of course also available in the new 2.1 release.

Major changes

In addition, version 2.1 Milestone 6 contains several major enhancements and new features summarized below.

  • Improved Restlet annotation value syntax to support alternate variants using ‘|’ and combination of several metadata for a single variant using ‘+’ separator. Also, all metadata are now supported, not just media types. In addition, support for URI query constraints was added to allow annotations such as @Get(“form:json?light”) or @Get(“?level=2”), working on both client and server side
  • Added org.restlet.ext.html extension supporting writing HTML forms in either URL encoded format or multipart form data, with the same FormDataSet class. Parsing of multipart form data isn’t supported yet.
  • Added CookieAuthenticator in the org.restlet.ext.crypto extension to provide customizable and secure authentication via cookies, in a way that is as compatible as possible with HTTP challenge based authentication
  • Added ConnegService providing a way to control the content negotiation behavior at the application level. It offers two modes: strict and flexible (default) but additional algorithms can be implemented.
  • Added org.restlet.ext.emf extension supporting the conversion between EMF generated beans and XML or XMI representations. It can also automatically write simple HTML representations for navigating your web API.
  • Added HTTPS server connector based on the internal non-blocking NIO connector. Co-developed with NetDev.
  • Many minor enhancement to the Restlet API for conveniency purpose such as a new Representation.append(Appendable) method.

API breaking change

When retrieving or updating the raw headers in the Request or Response attributes, the type should now be Series<Header> instead of Series<Parameter>


Recent contributors

  • Bryan Hunt
  • Cyril Lakech
  • David Bordoley
  • David Hamilton
  • Glenn Bruns
  • Jean-Pascal Boignard
  • Jeroen Goubert
  • John Logdson
  • Konstantin Pelykh
  • Martin Svensson
  • Nikhil Purushe
  • Ray Waldin
  • Remi Dewitte
  • Scott S. McCoy
  • Tim Peierls
  • Thomas Eskenazi

Thanks to all others who helped us in various ways for this milestone.

Additional resources

Changes log:

Download links:

Maven repositories:

Restlet Framework 2.1 M5 and 2.0.8 released June 21, 2011

Posted by Jerome Louvel in Restlet Releases.
Tags: , ,
add a comment

Today was an exciting day for Restlet. First Manning has published a new version of the “Restlet in Action” book in MEAP, including a new chapter covering cloud computing usage of the framework, leaving only two chapters to write (plus some refactoring based on reviews) in order to complete this effort. In addition, we have just released two new versions of the framework!

Bug fixed

First, the 2.0.8 version fixes a couple of issues on the stable branch including:

  • Annoying regression with JAXB due to improper TreeMap usage
  • Fixed regression introduced in 2.0.7 with WriterRepresentation, OutputRepresentation and subclasses when sending long entities (1024 and longer)
  • Fixed Range issue when handling large files
  • Fixed support for Content-Disposition header with HTTP server connectors

Those fixes are of course also available in the new 2.1 release.

Major changes

In addition, version 2.1 Milestone 5 contains several major enhancements and new features summarized below.

  • New “org.restlet.ext.oauth” extension added providing comprehensive support for OAuth 2.0 (draft 10) co-developped with Ericsson Labs. For additional details you can read the extension page in the user guide as well as the specifications page.
  • New “org.restlet.ext.openid” extension added providing initial support for OpenID 2.0 contributed by Ericsson Labs. For additional details you can read the extension page in the user guide as well as the specifications page.
  • Greatly stabilized the internal NIO based HTTP client and server connectors, now passing all our test cases. We are still fighting a couple of issues related to NIO reselection and HTTP pipelining and will complete HTTPS support for 2.1 RC1.
  • Moved all SSL logic within Restlet core into org.restlet.ext.ssl extension, adding a new dependency for some HTTP connectors.
  • Fixed compatbility issues with GWT 2.3.
  • Updated Jetty to version 7.4.2.


Recent contributors

  • Aaron Summers
  • John Logsdon
  • Julien Landuré
  • Kristoffer Gronowski
  • Martin Svensson
  • Tim Peierls
  • Tom Moore

Thanks to all others who helped us in various ways for this last milestone before 2.1 RC1.

Additional resources

Changes log:

Download links:


Maven repositories:

Restlet Framework 2.1 M4 and 2.0.7 released April 27, 2011

Posted by Jerome Louvel in GAE, Restlet Releases, SDC, Security.
add a comment

In order to adress several pressing issues, we are releasing those new versions one month after the previous release cycle. The good news is that we had time to add a couple of nice features to the 2.1 development branch!

Bug fixed

First, the 2.0.7 version fixes a couple of issues on the stable branch including:

  • Dormant threads in some IO operations due to excessive thread pool instantiation (via TaskService). Now a single temporary thread is used when an existing TaskService can’t be found.
  • Broken Amazon S3 authentication due to new AWS domain naming strategy
  • Cookies management interference when using the Apache HTTP client extension
  • Performance issue with JAXB serialization when used by the JAX-RS extension
  • Equality testing between Role instances wasn’t properly done (object identity testing)

Those fixes are of course also available in the new 2.1 release.

Major changes

In addition, version 2.1 Milestone 4 contains several major enhancements and new features summarized below.

  • The ClientResource#entityBuffering property now buffers non transient representations of unknown size. This change was necessary to fully prevent HTTP chunking when talking to a GAE backend (which forbids chunk encoding).
  • Refactoring of the SSL support to reduce the “org.restlet.jar” size by moving all SSL logic to the “org.restlet.ext.ssl” extension. Now other HTTP extensions including Jetty, Simple and Apache HTTP Client need to add this dependency. The SSL extension also includes an experimental HTTPS client that will be stabilized and completed with a HTTPS server in next milestone.
  • The simplified logging format (one line per log entry) used by default in the Java SE edition has now been disabled from the Java EE edition by default as it could interfer with logging behavior of some containers such as Tomcat
  • Throwing ResourceExceptions in ServerResource subclasses now properly preserves the given status code back to the client
  • The SDC protocol support added in 2.1 M3 via the “org.restlet.ext.sdc” extension is now available in the GAE edition via the “org.restlet.ext.net” extension, with the same syntax for better code portability between cloud platforms (Protocol.SDC and ChallengeScheme.SDC constants also added)
  • New “org.restlet.ext.gae” extension added to the GAE edition that supports authentication and enrolement based on the GAE users service
  • ClientResource now respects any change to the default client preferences when using dynamic proxies (via wrap() for example), such as change in preferred media types.

Recent contributors

  • Avi Flax
  • Bo Xing
  • Christoph Dietze
  • John Logsdon
  • Julien Landuré
  • Kristoffer Gronowski
  • Martin Svensson
  • Matt Kennedy
  • Michael Guiral
  • Rhett Sutphin
  • Tal Liron
  • Tim Peierls

Thanks to all others who helped us in various ways for this fourth milestone.

Additional resources

Changes log:

Download links:

Maven repositories:

Leveraging SDC beyond Google cloud with Restlet March 31, 2011

Posted by Jerome Louvel in Restlet, Restlet General, SDC.


When Google announced Secure Data Connector in 2009, it was welcomed with interest as it addressed people concerns regarding public cloud security and especially integration with their private information system.

SDC solves this cloud integration dilemma without requiring to open new ports on your firewall by establishing a reverse web proxy, called SDC Agent, that connects to an SDC Tunnel Server located in Google cloud infrastructure. Once established, the secure tunnel can be used in the opposite direction, from the Google cloud to your secure intranet by Google Sites, Google App Engine applications and Google Docs spreadsheets.

Missing features

While Google SDC is great if you fully live in the Google Apps ecosystem, it comes with several limitations:

  • SDC Agent is available as an open source project, but not the SDC Tunnel Server part
  • Google App Engine SDK doesn’t provide a way to test SDC locally without deploying your application
  • Can’t be used with other cloud platforms such as Amazon EC2 and Microsoft Azure
  • You can’t easily port a GAE application using SDC to another platform, private cloud or public cloud

As one of the Restlet Framework goals is to ensure a maximum portability across various Java based platforms such as GAE, GWT, Android and Java SE/EE those SDC challenges were compelling.

Restlet SDC connector

At the end of 2010, RunMyProcess, a long time Restlet user offering a cloud workflow solution as a cloud computing service, offered us to co-develop a Restlet SDC connector that would emulate Google SDC Tunnel Server and expose it like an HTTP client connector.

Thanks to the SDC Agent being available as open source, we could dive inside the implementation and understand the SDC protocol design which heavily relies on Google Protocol Buffer to implement a multiplexing tunnel (frames going both ways without constraint) over a TLS socket.

In the picture above, we illustrated how the Google SDC Agent software can be configured to connect to Restlet SDC Tunnel Server in the same way that you would do it for your Google Apps domain.

All the missing features are now supported by this Restlet extension which has just been released with version 2.1 M3 today! Thanks to RunMyProcess for co-developing this feature with Noelios Technologies.

You can find more technical details about this new feature in Restlet User Guide including sample usage code. Improvements are planned for a future release in order to increase the scalability of the connector by leveraging non blocking NIO/SSL connections or allowing load-balancing between a set of SDC Agent within the same intranet.

Update: RunMyProcess has now officially announced the support for this feature, see also press release

Restlet Framework 2.1 M3 and 2.0.6 released March 31, 2011

Posted by Jerome Louvel in NIO, Restlet, Restlet Releases, SDC, SIP.
1 comment so far

Past months have been very intense for Noelios in a positive way and we are pleased to release those two new versions today. Our long running effort to develop our own non-blocking NIO connector into Restlet core, comparable in performance to Jetty/Netty/Grizzly but simpler and directly aligned to HTTP/SIP transport semantics is starting to give great results.

First, the 2.0.6 version fixes a couple of issues on the stable branch. In addition, version 2.1 Milestone 3 contains several major enhancements and new features summarized below.

Main changes

  • Support for GWT 2.2 has been added, but due to breaking changes inside GWT core API, we couldn’t maintain compatibility with previous versions of GWT. If you can’t upgrade your GWT version, you can still rely on the 2.0 branch of Restlet.
  • Stabilized the built-in SIP and HTTP client and server connectors based on our non-blocking NIO core layer, refactoring the previous design and fixing many bugs. This should solve most issues related to blocked connections and infinite loops that were encountered. See this blog post for an official announce.
  • Added a new SDC extension providing a client connector for the Google Secure Data Connector protocol compatible with the official SDC agent. This allows usage of this feature during development phases as well as for deployment to private clouds and other public clouds such as Amazon EC2 and Microsoft Azure. See this blog post for an official announce.
  • Improved ClientResource class by adding several properties
    • requestEntityBuffering, responseEntityBuffering properties to make transient entities reusable (retry attempts, chunk encoding issues with GAE, response entity reuse)
    • maxRedirects property to prevent infinite redirects, in addition to the existing infinite loop detection.
  • Added an easy to listener mechanism that facilitates the support of asynchronous representation consumption. We tested this feature successfully by consuming live feeds from CouchDB.
  • Updated several dependencies including Jetty to version 7.3.0 and Jackson to version 1.7.1

Recent contributors

  • Andreas Taube
  • Carolyn Duby
  • Charlie Mason
  • Henry Story
  • Guido Schmidt
  • John Logsdon
  • Kristoffer Gronowski
  • Leandro Oliveira
  • Olivier Miel
  • Phil Dunks
  • Sebastien Gaide

Thanks to all others who helped us in various ways for this third milestone.

Additional resources

Changes log:

Download links:


Maven repositories:

Restlet Framework unifies VoIP and Web applications March 31, 2011

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


Noelios Technologies is proud to announce the release of Restlet Framework version 2.1 Milestone 3, its leading RESTful web framework for Java. This version includes stable client and server connectors for SIP (see specifications and user guide section), the core protocol for VoIP applications that were co-developed with NetDev.

NetDev’s point of view

NetDev is a provider of carrier-grade voice applications for communications service providers. We were one of the first companies to introduce RESTful web services into the telecoms space over three years ago. Back then we were looking for a lightweight method to communicate between services over the web and had previously used SOAP, which was heavy, cumbersome and difficult to understand. We found Restlet, with an architectural style true to the web, and began using it for provisioning and reporting of our applications. We soon extended its use for call control within the NetDev Audio Conferencing solution.

We’ve always been innovators and we got to thinking about how we could improve our customer proposition and reach new market segments, ultimately with the aim of winning more business. That’s when we started looking at a solution for VoIP deployments that could open up our applications to different customers. We considered using an Open Source SIP stack, but we were passionate about Restlet and that’s when we started talking to Noelios about adding SIP. For the project to be a success we needed Restlet to provide greater capacity, higher throughput and prove that our applications could run on it.

After many months work, the release of version 2.1 M3 represents the stabilisation of SIP Restlet and it’s a great achievement. At NetDev we have been working to port our Audio Conferencing Application from our existing container environments to Restlet. We’re delighted that this has now been achieved. We have successfully emulated all features in Restlet that were available in our previous software container. Not only that, but we’ve removed complexity and made development and deployment of applications simpler and much more economical.

For VoIP deployments we now have a suite of applications which don’t rely on commercial third party software or license fees and that’s going to open up new business opportunities for us. Essentially, we can offer cost effective, turnkey voice applications to any communications service provider with VoIP connectivity. We can also, through partnerships, pursue our cloud services offer, create new business models (revenue share & pay as you grow) because we have an efficient way to deliver our standard services. Of course, we will still work with our existing partners for customer deployments, but we now have the opportunity to address the markets that were previously closed to us.

Jointly with Noelios, we have brought Restlet into the telecoms world and have proved that its flexible architecture is easy to adapt in a new domain. In effect Restlet is now an Open Source, converged voice and web container, which we think is a great thing for telecoms. We will continue to jointly innovate with Noelios and encourage other telecoms companies to do the same!

Noelios’s point of view

Noelios is a provider of open source web middleware, specialized in the REST architecture style and web APIs. We created the open source Restlet Framework 6 years ago and are leading its development with the support of our community. We have an active community, including independent developers as well as large organizations such as Google, IBM, Microsoft, Ericsson Research or the NASA.

We offer consulting services, technical support and legal protection to Restlet users all over the world. This includes co-development services for customers willing to sponsor and collaborate with Noelios in order to bring new features in Restlet. In this regard, NetDev has been exemplary, leveraging the full range of our offer and understanding the economics of open source software development.

We have been working with them for 3 years, initially on their RESTful web services needs and progressively became knowledgeable about the VoIP world, its strong performance requirements and its core SIP protocol for which NetDev collaborates with the best industry experts.

The Restlet/SIP connector that we co-developed with NetDev opens new doors for usage of Restlet beyond its Web roots and reinforces its position as a unified development framework. This project which is available in the new 2.1 M3 version, adds a great value to our technology.

We are delighted to open Restlet to the telecom world with NetDev and encourage other companies to join our community and develop an ecosystem around this foundation as an alternative to traditional, complex and heavier SIP stacks such as JAIN SLEE and SIP Servlets, keeping alignment with Internet standards, lightweight, simplicity and performance as key characteristics!


We would also like to thank other contributors that helped during the Restlet SIP specifications phase:

  • Vincent Nonnenmacher (TelNowLedge)
  • Kristoffer Gronowski (Ericsson Research)


“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