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!


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!

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 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

Early access to Restlet in Action book November 5, 2009

Posted by Jerome Louvel in Restlet General.

Since the announce of the book last August, we worked hard to write the first chapters, enhance their quality with our development editors and improve the table of contents. In parallel, the Restlet Framework has been quickly moving forward, with Restlet 2.0 M5 released in September and a first release candidate scheduled for the end of the year!

Today, Manning has released the early access version of the book (MEAP is Manning Early Access Program) . It gives you the first chapter for free and lets you buy the book to read the other chapters, as soon as they are released. If you purchase the print book version, you will be able to read the electronic version while the book is being completed and then a printed version will be automatically mailed to you by Manning.

Restlet in Action

This early access version is a great opportunity to get you started with version 2.0 of the Restlet Framework and with the design of RESTful Web APIs in general. It also gives you an opportunity to exchange with the authors through a dedicated forum on Manning’s site and help us improve the content and structure while we add more chapters.

Restlet bridges ADO.NET Data Services and Java September 28, 2009

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

After a successful collaboration in February with Microsoft, we continued to explore the interoperability opportunities between Microsoft and Java technologies, leveraging REST and Restlet. Today, we are happy to announce the result of several months of hard work: a new interoperability bridge between Java and ADO.NET Data Services!

Microsoft’s strategy

In order to understand how central the Web and REST are becoming for Microsoft, it is enlightening to discover their new strategy elaborated by Ray Ozzie, Microsoft’s Chief Software Architect. It is called Software + Services and recognizes the ubiquity of the Web and the need to mix both locally running software and cloud computing services in a unified way.

Software + Services

From vision to reality, there is often a long way to go, but this time Microsoft is serious about the Web and genuinely embracing REST. For a few years now, they have been progressively building on their strategy, through Windows Azure, a comprehensive cloud computing platform, and through online extensions to their classic products like Office Live, XBox Live or Windows Live.

ADO.NET Data Services

One of the key technologies they leverage to achieve their plans was launched in 2007 under the code name “Astoria”. It drew much attention in the REST community at this time as it was, with Ruby on Rails’s Active Resource technology, the sole way to automatically expose a data models as RESTful Web services.


Since then, it has matured and became an actively maintained technology called ADO.NET Data Services. You can read an overview paper on MSDN and browse their extensive technical documentation for details about their REST API which leverages AtomPub.

Interoperability with Java

As RESTful Web services, you could use any HTTP toolkit to access them, to the exception of the authentication step which relies on a custom scheme, quite similar to the one used by Amazon for its Web services. However, you are not very productive this way, especially when you know that ADO.NET Data Services describe themselves through extensive metadata.

So far, beside client toolkits for Microsoft technologies such as .NET and Silverlight, only the PHP language had an easy solution to interact with those services. Today, with the release of Restlet 2.0 M5, we are proud to announce a similar offer for Java developers, cleanly leveraging the Restlet Framework.


With the support from Microsoft and especially Stève Sfartz, Architect Lead at Microsoft France, we built a high level client that is able to generate client Java classes from exposed metadata and to easily manipulate the remote entities as if they were local. The current feature scope covers most of the use cases, but keep in mind that we don’t cover all the available features available yet.

This new Restlet extension has been extensively covered by Jean-Christophe Cimetiere, Sr. Technical Evangelist from Microsoft Corp Interoperability team, in this new blog post.

Extension documentation

In order to briefly illustrate how the extension works, you can read the dedicated extension page in the Restlet user guide. It shows some simple code to access to a data service, one provided for the Open Government Data Initiative (OGDI), a recent effort launched by Microsoft to expose government data sources as RESTful Web services.

In addition, to the regular Javadocs of the extension, a complete tutorial is also available on the wiki to get you started in minutes with a detailed example. Now, if you have a .NET developer friend, you could ping him and set-up a plug scenario!

Launch coverage

Announcing Restlet in Action book August 24, 2009

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

We are very happy to announce that we have agreed with Manning to publish a “Restlet in Action” book that will cover in depth the upcoming 2.0 version of the Restlet Framework.

Our goal is to have the book published in fall 2010. However, you will not have to wait so long to start reading it… You will be able to use Manning Early Access Program (MEAP) to get an online access to draft chapters as they are written. This will give you an opportunity to send us feed-back via an online forum.

Restlet in Action

Even better, you can download the green paper “Rethinking Web Development with REST and Restlet” that was published today on Manning’s site and that is based on the chapter 1. Here is also the expected table contents:

Part 1: Getting Started

  • 1. Rethinking web development
  • 2. Designing a RESTful web API
  • 3. Beginning a Restlet application
  • 4. Deploying a Restlet application on premises

Part 2: Getting Ready To Roll Out

  • 5. Producing and consuming Restlet representations
  • 6. Securing a Restlet application
  • 7. Documenting a RESTful web API
  • 8. Enhancing a Restlet application

Part 3: Further Usage Possibilities

  • 9. Deploying a Restlet application in the cloud
  • 10. Using Restlet in browsers and mobile devices
  • 11. Embracing the semantic Web
  • 12. Looking beyond this book

As always, we are looking forward to getting your feed-back on this project, what you expect from it, what you think about the green paper and the overall table of contents.

Update 1: The table of contents has been refreshed to match the latest manuscript version

Update 2: The book is now available in early access !

Part 1: Getting Started
1 Rethinking Web development
2 Designing your REST API
3 Creating your Restlet application
4 Deploying your Restlet application
Part 2: Getting Ready To Roll Out
5 Enhancing your Restlet application
6 Securing your Restlet application
7 Documenting your REST API
8 Embracing the Semantic Web
Part 3: Further Usage Possibilities
9 Using Restlet in the cloud with Google App Engine
10 Using Restlet in browsers with Google Web Toolkit
11 Using Restlet on mobile Android devices
12 Looking beyond this book