jump to navigation

New release of APISpark rolled out May 21, 2013

Posted by Jerome Louvel in APISpark, Restlet General.
add a comment

Today we are rolling out a third release of APISpark beta. The previous releases are described in blog posts #1 and #2. If you want an access to the beta, please share your interest in APISpark on Twitter (@apispark).

Also, you might want to read our latest “How much REST should your web API get?” blog post and the following discussion. Now, let’s continue with an overview of the changes released in production today!

Complex entities & representations

First, we added support for one of the most requested features: the ability to define and persist relationships between entities, including association, aggregation and composition.

We also added support for abstract entities and ensured that when automatically creating an API from an entity store via the import wizard, we expose complex entities via matching complex representations.


The Java and JavaScript client SDKs, the offline HTML and PDF documentations have also been updated to either use or describe complex representations. We will soon update the iOS client SDK as well.

API templates and contracts

APISpark can not only create a web API from scratch or from an imported entity store, it can also let you create a web API based on an API template. You can think of them as blog themes on WordPress.com that lets you create your own custom blog in just seconds.

New API templates can be created from scratch or from a complete API that has been already deployed and tested. See the “Extract template” action in the drop-down menu below.


Those templates then appear in your dashboard, with an icon surrounded by a thick orange border as illustrated below and can be reused to create new APIs.


Like complete web APIs, public templates can be promoted to APISpark Catalog. Instances can then be created in seconds, each having its own runtime, including dedicated HTTP endpoints, members or analytics data.

The API contract and implementation are not cloned and remain controlled by the origin template. A similar feature just for API contracts is also provided, only including the visible aspects of a web API including the list of resources, methods, representations and client SDKs.


API contracts have several benefits for API users including easy switching from one API provider to another, or calling multiple APIs supporting the same contract but exposing different data.

Enhanced API implementation

When you deploy an API with APISpark, we internally generate some source code that has the Restlet Framework as main dependency. This source code is then compiled and packaged before being hosted by APISpark.

Restlet Framework

We try to generate this code exactly like a Restlet Framework developer would have written it. This means that your web APIs created by APISpark can be as performant in production as those written by hand. APISpark doesn’t interpret web APIs at runtime, but execute them at full byte code speed.

In this release, we have enhanced the implementation layer of APIs with:

  • added support for multiple actions

  • implemented action types (call imported API / call imported store / return response)

  • streamlined generated mapping code for speedier execution time

  • other APIs can now be imported and invoked (composite APIs)

Upgraded to Cassandra 1.2

APISpark enable you to store structured data via local entity stores, and later expose them through one or multiple web APIs.

In order to support efficient multi-tenant hosting, we rely on Apache Cassandra. Even though this technology choice is not directly visible to APISpark developers, it is key for us to provide:

  • potentially unlimited entity store sizes, spreading across machine clusters

  • highly-available entity stores thanks to continuous replication across mutiple machines

  • live entity store schema modifications without having to restart the database

  • flexible replication schemes including multi-region deployments

Cassandra logo

In this new release of APISpark, we have refactored our persistence layer, upgrading to version 1.2 of Cassandra which brings new features: 

  • better multi-tenant performance for concurrent schema changes on entity stores

  • better scalability and fail-over behavior thanks to virtual nodes

  • speadier access thanks to new native driver

  • support for repeating properties thanks to the new collections feature in CQL3

Even though you don’t have a direct access to the low-level Cassandra database powering APISpark entity store, we want to let you know that we use the best-of-breed cloud database technology to power web APIs hosted on APISpark.

We are also working on entity store wrappers for data living outside APISpark platform to let you reexpose them through proper web APIs. Stay tuned for the next release of APISpark for more information about this feature.

Improved stability

In addition, we have started to roll-out intra-region fail-over support to ensure that your APIs hosted by APISpark are highly available in case of hardware failure. Currently APISpark runs from the Northen California data center of Amazon Web Services.


The next step is to roll-out the multi-region deployment with a second data center in Virginia so that in case a complete AWS region goes down (which is very rare but already occured in the past), your web API can still run out of the other region in a way that is almost transparent to your API users, beside the increased network latency.

Finally, we fixed several issues:

  • URI path variables are now declared when adding resources from imported entity stores

  • Adding multiple sources selection in the Mapping panel

  • Adding mapping support for path variables and query parameters when calling an API

  • Fixed API contract filtering on the dashboard

Getting started

If you want to see how creating, hosting and using web APIs looks like with APISpark, we recommend our first tutorial. 

How much REST should your web API get? May 2, 2013

Posted by Jerome Louvel in HTTP, REST, Restlet General, Semantic Web, Uncategorized.
Tags: ,

There is an ongoing debate regarding the proper way to design web APIs. This is often related to the following terms:

Recently, I read “Getting hyper about hypermedia APIs“, a blog post from David H. Hansson (Rails’s creator). Looking at both the quality of his arguments and the defensiveness of the readers’ comments, he clearly hit a nerve.

To understand why this is important, let’s compare the REST and Web API architecture styles in tension.

REST style, as defined by Roy T. Fielding

REST was formally defined in 2000 for systems that are both distributed and driven by hypermedia interactions with humans.

Fully embracing it requires you to respect the 5 mandatory constraints (plus an optional one), as described below.

Note that this summary contains large excerpts from Roy T. Fielding’s thesis:

1 – Client-Server constraint

  • separation of concerns
  • client = user interface concerns (
  • better UI portability across platforms)
  • server = data storage concerns (more
  • simple and scalable implementations)
  • independent evolution of clients and servers at Internet scale

2 – Stateless constraint

  • each client request must contain all the info necessary for the server to respond
  • session state is kept entirely on the client

3 – Cache constraint

  • allow client to reuse response data in a controlled manner
  • support intermediaries such as proxies and shared caches

4 – Uniform Interface constraint

  • central and unique feature of REST
  • less efficient than a customized interface due to the standardization overhead
  • efficient for large-grain hypermedia data transfers
  • not optimal for other forms of architectural interaction
  • sub-constraints
    • identification of resources via URIs
    • manipulation of resources through representations (HTML hyperlinks, forms or JavaScript/AJAX style)
    • self-descriptive messages
    • hypermedia as the engine of application state (HATEOAS)

5 – Layered System constraint

  • each component only knows about the immediate component/layer it is interacting with
  • favor intermediary components (load-balancers, reverse proxies, shared caches)
  • can add overhead and latency
  • gives pipe-and-filter benefits (combined with Uniform Interface constraint)

6 – Code on demand constraint [optional]

  • client component doesn’t know how to process the resources it has access to
  • code representing this know-how is retrieved by the client and executed locally
  • dynamic feature addition to deployed clients
  • improved extensibility and configurability
  • better user-perceived performance and flexibility
  • improved server scalability (offload work to the client)
  • lack of visibility requires client to trust the server (security sandboxing required)

In addition to these constraints, REST also defines as a set of architectural elements that directly abstract the semantics of the HTTP application protocol:

  • data elements
    • resource (conceptual target)
    • resource identifier (typically an URI)
    • representation (HTML document, bitmap image)
    • representation metadata (media type, modification date)
    • resource metadata (allowed methods, alternates)
    • control data (content negotiation, conditional requests, compression)
  • connectors (client, server, resolver, tunnel)
  • components (origin server, user agent, gateway, proxy)

Finally, REST defines three views that illustrates the style including the process, connector and data view. The last one illustrates what a REST client can be:

  • primarily an hypermedia browser, including ability to do incremental rendering
  • an automated robot performing information retrieval for an indexing service
  • a personal agent looking for data that matches certain criteria
  • a maintenance spider busy patrolling the information for broken references or modified content

End of excerpts.

The web of documents and browsers, as we know it, is the best example of the REST style in action. This is logical as REST was inferred from the earlier Web architecture during the specification of HTTP version 1.1.

However, looking at Roy T. Fielding recurrent reactions regarding the improper usage of “REST” as a buzzword, it is time to question whether the REST style can be or should be used when building regular Web APIs.

Web API style, as practiced today

Web APIs are designed for systems that are both distributed and driven by machine-to-machine interactions.

This Web API style is the result of the evolution of pragmatic development practices since 2000, starting with the emergence of Web Services (WS-* and *-RPC) and then the strong influence of the REST style towards more simplification and proper usage of HTTP as an application level protocol rather than a lower-level transport protocol.

Let’s attempt to formalize this style in a way similar to REST. Embracing it requires you to respect the 6 constraints described below:

1 - Client-Server constraint

  • separation of concerns
  • client = program with varying concerns (maximum reusability needs)
  • server = data or logic accessibility concerns (build ecosystems of innovation)
  • independent evolution of clients and servers at Application scale
  • significant difference from REST

2 - Stateless constraint

  • identical to REST

3 - Cache constraint

  • identical to REST

4 - Custom Interface constraint

  • predefined set of resources including identifiers and representations
    • cool URIs that don’t change
    • developers friendly URI naming based on conventions
  • more efficient than dynamic discovery
  • requires coordination between clients and servers when changes are deployed
    • based on explicit versionning
  • efficient for both small-grain mobile data transfers as well as large-grain data transfers
    • based on parameterized resources and content negotiation
  • not optimal for other forms of architectural interaction
  • sub-constraints
    • identification of resources via URIs (identical to REST)
    • manipulation of resources through low-level HTTP clients (using for example raw JSON or XML representations)
    • manipulation of resources through high-level client SDKs (for major programming environments) when available
    • developer documentation to help with understanding of the interface
  • significant difference from REST

5 - Layered System constraint

  • identical to REST

6 – Mobility constraint

  • intermittent Internet connectivity
    • potentially unavailable for a long time
    • requires an off-line application mode
  • expansive Internet connectivity
    • typical mobile data plans have data limits per months
    • ability to switch to less expansive radio networks when available
    • highly dependent on actual client location
  • irregular bandwidth (potentially very low)
    • adjust media size dynamically
  • irregular latency (potential very high)
    • aggressively use cache (by default)
    • synchronize cache when possible
  • not present in REST

As you can see the Web API style has been very much influenced by REST and share many of its constraints. This influence over 10 years has resulted in key simplifications compared to the original RPC style to make it more aligned with the core Web concepts such as resources, URIs, representations and the HTTP protocol.

REST and Web API styles are web brothers

There is no reason to oppose both styles as they are not solving the same problems, even though they are both deeply connected with the Web. The figure below represents their main differences.


Both styles are complementary and can be used together, for example when building a single page web application where the main HTML is loaded through a regular web page (REST style), including some JavaScript (code on demand constraint). This code is then interpreted by the web browser to make AJAX calls back to a Web API, exchanging predefined JSON representations.

Let’s also mention hyperdata as a second form of hypermedia with hypertext, that also offers a comprehensive application of REST. This is the world of the Semantic Web and especially the pragmatic Linked Data movement based on RDF and related media types such as Turtle, JSON-LD or HAL.

In other situations, where the client isn’t a web browser but a native mobile app, a connected device or a program written by a partner to integrate your web site with their own, you only rely on the Web API style, which is fine again. Let’s now step back and see where these new forms of web architectures will lead us.

Building cross-device web sites

By combining the power of REST (the web of documents) and of Web APIs (the programmable web), we can build a new generation of web sites that are inherently cross-device. as illustrated below.

Cross-device web sites

Those web sites let organizations of all sizes provide a pervasive and contextual access to their information and services, to both customers, employees and partners via potentially any kind of machine.

I will wrote more about cross-device web sites in future posts as they help understand the strategic value brought by Web APIs in this new era of mobility.


Extended APISpark public beta ready April 4, 2013

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

Thanks to your feed-back, we have spent the past month improving APISpark with more stability and new features. Find below and overview of the changes available in production!

We are also extending access to the public beta to even more users in the waiting list.

Faster API deployment

We have significantly reduced the API deployment time by moving the generation of downloadable elements (client SDKs and offline documentation) to a separate action.

See the new “Generate downloads” action in the actions menu below.

Generate downloads action

In addition, we fixed a regression with the iOS client SDK that what causing it to include unecessary and large files. The result is a faster generation of downloads as well.

Flexible life cycle

Based on your feed-back (special thanks to Rob Bontekoe), we realized that the difference between Deploy and Publish actions isn’t clear.

To summarize, Publish is an action that moves draft APIs or Data Stores forward in their life cycle. Once published, the Deprecate action is then available and finally Archive.

Life cycle

On the contrary, the Deploy action is always available and doesn’t change the status of a cell (API or Data Store), it only regenerates and updates it on the runtime platform.

Now, when an API is published, it becomes impossible to change its contract in order to prevent breaking users’ applications. If changes need to be made, it is however possible to create a new version of the API in parallel which will be in Draft mode.

Revert to draft action

However, while users are discovering APISpark, they are tempted to publish an API and then changing their mind before inviting external API users. For this case, we added a new “Revert to draft” action to the drop down menu as illustrated above.

Custom domain names

Each API created on APISpark is given a subdomain such as mycompany.apispark.net which is an easy way to get started. However, more advanced API projects will prefer to use their own domain name such as api.mycompany.com.

We are pleased to announce that custom domains are now available on APISpark. They can be added to an API by going to the “All versions” level in the version combo box, then using the Domains section as illustrated below.

Domain names

Please note that you need to add a new DNS record to your DNS registry in order to properly route the traffic to your API hosted by APISpark.

Once enabled, you can return to any API version and create a new endpoint, selecting the new domain name. Redeploy your API and you are good to go!

Improved stability

Finally, we fixed several issues:

  • Fixed conflict when deploying an API and a Store with the same name
  • API deletion is not complete, including the release of the domain name
  • Completed the offline HTML doc generated, including a light CSS
  • Fixed regression when generating the offline PDF doc
  • Improved sign in by giving feed-back to unauthorized users
  • Improved sign out by redirecting to the APISpark.com home page
  • Security rights and action conditions weren’t displayed properly in UI
  • URI path variables are now generated by the “Add resources” wizard
  • Merged Info, Copyright & User Agreement sections
  • Entity, Resource & Representation names restricted to a-z, 0-9 and ‘_’

Updated road map

Based on our progress and the feed-back received, we have refined our road map for the next few months, with the release of version 1.0 expected for June 2013.

Road map

Select the road map picture above for additional details.

Getting started

If you want to see how creating, hosting and using web APIs looks like with APISpark, we recommend our first tutorial.

Restlet Framework 2.1.2 and 2.2 M3 released March 8, 2013

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

We are happy to release two new versions of Restlet Framework along with the start of the public beta of APISpark.

Brand new web sites

The design of the project web site didn’t change for more than 4 years. It was time for a fresh new start!

During this redesign effort, we had several goals in mind:

  • Easier discovery of the framework
    • main features overview (with visual icons)
    • user quotes, first steps tutorial, FAQ
  • Cutomized download experience
    • we remember your preferred release/version and edition
    • customized Maven and Eclipse update instructions (TBD)
  • Improved documentation
    • migration of old wiki’s to new site (Learn and Participate sections)
    • easier contribution with GitHub MarkDown and Pull Requests
    • unified roadmap (old site and developers’ wiki pages merged)
  • Easier navigation between our connected web sites:
  • A more modern look & feel
    • based on jQuery
    • new logo!

Logo Restlet Framework

Please be aware that the migration of the old wiki content is still underway and that there are broken links and missing images. For those who want to help us fix those issues, please use the GitHub repository for those web sites and submit pull requests.

2.2 branch (testing)

In addition, here are the main changes made:

  • Added JSONP filter to wrap JSON representations as JS callbacks
  • Refactored OAuth 2.0 extension to a single public package (see JavaDocs)
  • Refactored JacksonRepresentation to merge the JacksonSmileRepresentation
  • Added Request/Response.flushBuffers() method to force IO flush
  • Removed old code deprecated in version 2.1
  • Added HTTP PATCH related methods to the ConverterService, ClientResource and ServerResource
  • ConverterService is now more explicit about errors, throwing IOExceptions
  • Refactored Role support to facilitate comparison, adding parent Application property
  • Moved TaskService from Application to Component, to share it between apps
  • All bugs fixes from version 2.1.2

2.1 branch (stable)

We also release version 2.1.2 fixing a dozen of bugs including:

  • Stabilization of the internal HTTP/HTTPS connector (more work needed)
  • IPv6 addresses support
  • XSLT Transformer and TransformRepresentation chaining

Recent contributors

  • Brian Sletten
  • Cyril Lakech
  • Daniel Halperin
  • Koen Maes
  • Mark Kharitonov
  • Martin Svensson
  • Neha Saini
  • Nicolas Rinaudo
  • Peter Ansell
  • Reddy Lakshman
  • Tim Peierls
  • Yan Pujante

Thanks to all others who helped us in various ways.

Additional resources

Changes log:

Download links:

APISpark public beta started! February 25, 2013

Posted by Jerome Louvel in APISpark, Restlet General.

After 2 years of R&D and following our announce of APISpark à GigaOM Mobilize last September, our team has been working intensly to complete and stabilize our public beta version.

APISpark logo

Today, we are very excited to launch it, starting with the initial list of persons who signed up to get an access to the beta. If you haven’t done so yet, please make sure to sign up here, first come first serve!

Road map

Starting this month, we will be progressively giving access to more and more beta testers, with new releases once a month. As illustrated in the visual roadmap below (click on it for details), we plan to reach 1.0 in May 2013.Road Map Until then, we want to get as much testers and feed-back as possible and make 1.0 the highest quality product possible. Please also make sure to share with us ideas for enhancements and new features.

Getting started

If you already have access to the public beta or if you want to see how creating, hosting, managing and using web APIs looks like with APISpark, we recommend our first article in our tutorial series.


If you have any question, you can freely reach us during the beta phase on all available support channels:

Early testers

Finally, we would like to thank all the persons who gave us invaluable feed-back during the project inception.

We can’t mention everyone, the list would be too long, but we would like to highlight the persons who test drived the product with proof of concepts and interactive demo sessions:

  • Alexis Menard
  • Guillaume Laforge, Groovy
  • Frederic Renouard, EIT ICT Labs
  • Jean-Paul Figer, ARMOSC
  • Mikros Image R&D team (Antonio Fiestas, Benoit Maujean, Guillaume Chatelet, Guillaume Maucomble, Michael Guiral and Thomas Eskenazi)
  • Philippe Converset, AutreSphere
  • SFEIR team (Aurélien Pelletier, Didier Girard, Salvador Diaz and Thierry Lau)
  • Stève Sfartz, Kosmos
  • Yan Pujante

Coverage (update)

Restlet Framework 2.1.1 and 2.2 M1 released December 26, 2012

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

We are happy to release two new versions of the Restlet Framework today. After a rather lengthy 2.1 release cycle due to the writing of the ‘Restlet in Action’ book, we want 2.2 development to last one year, with a release planned in summer 2013. See our detailed roadmap.

Stable 2.1 branch

We first released version 2.1.1 which fixes a dozen of bugs and marks the “2.1″ branch as the new stable branch. As a result, the “2.0″ branch has now reached its end of life, after about two years of maintenance since the release of 2.0.0. New releases will only be made if critical security bugs are found or for customers with professional support plans.

We now encourage everyone to migrate to version 2.1.1 for their Restlet applications in production, which should be easy from 2.0. See our migration guide for help on that front.

The internal HTTP connector has received several fixes and improvements, but we don’t consider it ready for heavy productions yet. We will keep improving its stability and scalability in the future 2.1.x revisions.

Testing 2.2 branch

The first major change is that the minimum requirement are now Java SE/EE 6 (including Servlet 3.0) . As a result, we were able to upgrade our Jetty extension to use version 8.1 of Jetty.

We no longer support Java 5 which has been the case since Restlet Framework version 1.0. If you still need to support Java 5 due to other requirements, we encourage you to keep using Restlet Framework 2.1.


Today, modern web API rely on OAuth 2.0 to secure access, providing revokable and delegable authorization. It is key for the Restlet Framework to fully support this standard on both the client and server sides.

With this first 2.2 milestone, the OAuth 2.0 extension has been upgraded to OAuth 2.0 draft 30 level. We still have a lot of work ahead to both fully support the final 2.0 version of the specification (RFC 6749), both on client and server side, and to update the documentation (Javadocs and user guide).


As this point, this extension is still considered experimental and we are looking for additional testers and contributors.

In addition, here are additional changes available:

  • HTTP PATCH method (RFC 5789) is now supported by default via Method.PATCH constant and @Patch annotation
  • JAX-RS extension has been enhanced to add client-side support based on JAX-RS annotations
  • Jackson extension has added support for the JSON binary (Smile), XML, YAML and CSV formats
  • OSGi extension has an OBAP pseudo-protocol (OSGi Bundle Access Protocol) client connector to allow access to resources from other OSGi bundles.
    • URI scheme: “obap://{bundleSymbolicName}/{pathToResource}”

Recent contributors

  • Andy Dennie
  • Brian Sletten
  • Dennis Mitchell
  • Emmanuel Liossis
  • Emanuele Ziglioli
  • Florian Bucklers
  • Grzegorz Godlewski
  • Jeff Plourde
  • Laurent Rustuel
  • Martin Grohmann
  • Nicolas Rinaudo
  • Shaun Elliott
  • Shotaro Uchida
  • Tim Peierls
  • Wei Wei Wang

Thanks to all others who helped us in various ways.

Additional resources

Changes log:

Download links:

‘Restlet in Action’ book available in print October 19, 2012

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


Early on, users of Restlet Framework asked for better and more complete documentation and it became clear that we needed to make serious efforts on this front. At the end of 2008, we started to look for a publisher that would support our idea of a Restlet book.

When Guillaume Laforge, head of Groovy development, told us that Manning was looking for exciting new technology to cover, it was clear that a “Restlet in Action” book would be ideal, especially with their early access program that would give to the community a quick access to the electronic version of the draft manuscript, and provide us some continuous and valuable feed-back along the writing process.

Philippe Mougin, a web services expert, joined us for a few months and contributed important content on REST, such on proper URI design and a comparison with the RPC style. In addition, Bruno Harbulot, a Ph. D. from the University of Manchester who had been instrumental during the design of the Restlet security API, contributed the initial content of the security chapter.

Later in 2010, Thierry Templier, a Java EE expert and author of several books published by Manning, started to collaborate with us on the Restlet project and became the third co-author, contributing two chapters the cloud, GWT and Android as well as content on Spring integration, OSGi deployment and the security. He is now part of our team, focusing especially on the development of our new APISpark platform as a server and on the Restlet Framework editions for JavaScript and OSGi.

In addition, Tim Peierls, co-author of the Java Concurrency in Practice book and a key contributor from the Restlet community, made a great technical review of the draft manuscript. He also contributed a new introduction to chapter 1 and worked hard to improve the overall manuscript English fluency.

Finally, after three years of intense efforts, Restlet in Action is finally ready for a new life in the world of book stores and libraries. Speaking for all the co-authors and all the contributors of this book, I hope that you will enjoy reading it and developing RESTful web APIs using the Restlet Framework!

Table of contents

Part 1 Getting started

  • Chapter 1 Introducing the Restlet Framework
  • Chapter 2 Beginning a Restlet application
  • Chapter 3 Deploying a Restlet application

Part 2 Getting ready to roll out

  • Chapter 4 Producing and consuming Restlet representations
  • Chapter 5 Securing a Restlet application
  • Chapter 6 Documenting and versioning a Restlet application
  • Chapter 7 Enhancing a Restlet application with recipes and best practices

Part 3 Further use possibilities

  • Chapter 8 Using Restlet with cloud platforms
  • Chapter 9 Using Restlet in browsers and mobile devices
  • Chapter 10 Embracing hypermedia and the Semantic Web
  • Chapter 11 The future of Restlet


  • appendix A Overview of the Restlet Framework
  • appendix B Installing the Restlet Framework
  • appendix C Introducing the REST architecture style
  • appendix D Designing a RESTful web API
  • appendix E Mapping REST, HTTP, and the Restlet API
  • appendix F Getting additional help

Launch party

Last Wednesday, we had a great party to celebrate the launch of the printed book which is now available from major bookstores such as Amazon.com. The party was hosted near Paris by SFEIR, an innovative IT integrator and long time supporter of the Restlet project.

The event was organized thanks to the support of Didier Girard (COO of SFEIR) and Aurélien Pelletier (CTO of SFEIR). In less than a week, we had the event sold out and about 50 persons showed up, which was really nice with such a short term notice!

I started with a presentation of the Web APIs ecosystem, an introduction to the Restlet Framework, a comparison between the Restlet API and the JAX-RS API, an outlook of the latest version 2.1 and the roadmap for version 2.2 which will have a shorter release cycle (1 year).

Finally, I took this opportunity to present APISpark, our innovative Platform as a Service for RESTful web APIs and our latest progress toward our public beta version.

We continued with a panel of web API experts including Jean-Paul Figer (ex-CTO of Cap Gemini, President of ARMOSC), Christian Fauré (software architect and philosopher), Aurélien Pelletier and myself, with Didier Girard as the master of ceremony. The debate was engaged and the room took the opportunity to ask questions and interact in a constructive way.

You could feel the growing interest in web APIs with questions on API business models and even licensing issues! For those who missed the event (in French), there is a Google Hangout recording available on YouTube.

Thanks you all for your support during the book elaboration, writing and launch steps. With your help, we finally made it to the book stores!!

Best regards,
Jérôme Louvel

Update: see blog post from SFEIR about the launch party

Restlet Framework 2.1.0 released! September 27, 2012

Posted by Jerome Louvel in Restlet Releases.

After two years of development, we are proud to release version 2.1.0 of the Restlet Framework, in sync with the publishing of the ‘Restlet in Action’ book !!

What’s new?

Let’s step back and review the major enhancements introduced since version 2.0. For complete details, you can consult the related user guide page.

Restlet API

  • Support for more asynchronous representations has been added to faciliate interaction with streaming APIs such as CouchDB or Twitter
  • The annotations syntax has been enhanced to allow query parameters or alternate variants matching
  • Many syntactic sugar has been added such as getAttribute(name), getQueryValue(name), getMatrixValue(name) methods and equivalent setters on Resource subclasses
  • Improved ClientResource with a buffering option (useful for GAE which lacks chunked encoding support), redirection loops prevention and URI template support
  • New EncoderService added to automatically compress entities sent on both the client and the server side
  • New ConnegService providing a way to control the content negotiation behavior at the application level


  • Brand new internal connectors for HTTP added based on non-blocking NIO with limited thread usage
    • This is ideal for development phase and once fully stabilized should become an alternative for production
  • Greatly improved logging system, based on JULI, with programmatic control of the log level and the message formatters


  • Updated Crypto extension with support for AWS authentication schemes, both client and server side
  • Added EMF extension supporting automatic representation serialization to XMI, XML and HTML
  • Updated GAE extension to add special authenticator (only GAE edition)
  • Added HTML extension supporting multipart forms on the client-side (can be combined with the FileUpload extension)
  • Added OAuth extension support version 2.0 (draft 10). More recent drafts are supported in version 2.2
  • Added SDC extension supporting Google Secure Data Connector protocol on the client-side (facilitate migration between GAE and other PaaS)
  • Added SIP extension providing both client and server connector for VoIP, based on the internal HTTP connector
  • Added SSL extension providing internal HTTPS client and server connectors
  • Various dependencies were updated such as FreeMarker 2.3.11, Jetty 7.6.5, Jackson 1.9.8 or XStream 1.4.1


  • Support for GWT from version 2.2 to 2.5 was added
  • Added edition for OSGi environments including dynamically generated bundle manifests, and removing the presence of activator class in other editions

Revamped community support

  • Migrated from Tigris.org to GitHub regarding the source code and the issue tracker has been completed, leading to more contributions
  • Added StackOverflow as the preferred source of user Q&A
  • Maven repository is now refreshed daily
  • Apache 2.0 license option was added
  • Twitter accounts were added:
    • @restlet_org for tweets related to Restlet open source project
    • @apispark for APISpark, the PaaS edition of Restlet Framework
    • @jlouvel for tweets from Restlet Framework’s creator

Major contributors

We don’t have the space to thank all direct contributors here, but you can find their names in the changes log below or in previous blog posts. Thank you all, your contributions made a big difference!

What’s next

Seven years after the project launch, the project is entering a new phase. REST is now the de facto standard and web APIs are popping up every day with 1 million web APIs expected in 2017.

At Restlet, we look forward to helping you and many others to be part of this growing API providers community. Of course you can always create your custom API using the Restlet Framework, but now we also offer a new solution.

APISpark is an all-in-one Platform as a Service that takes care of the creation, hosting, management and usage of web APIs, including both the visible API contract as well as its underlying implementation including data stores.

Support for third-party API wrappers and easy to use API templates are also built in the platform and made available through an API catalog that can be populated by API providers and searched by API users.

We also have a roadmap for version 2.2 of Restlet Framework which will add enhancements such as migration to Java 6 and Servlet 3.0, optimized size for GWT and Android editions by providing ligther JAR profiles, better Javadocs by merging the content of the user guide currently in the wiki, and so on.

The first milestone should come pretty soon and will mark the 2.1 branch as the new “stable” branch, fully ready for production. Until, then please test 2.1.0 in your environment and report any issue you find!

Best regards,

Jérôme Louvel – Founder and lead developer
ThierryBoileau – Community manager and core developer
Thierry Templier – Core developer

Additional resources

Changes log:

Download links:

Launching APISpark at GigaOM Mobilize 2012! August 23, 2012

Posted by Jerome Louvel in APISpark, Restlet General.

The end of 2012 is full of exciting changes for Restlet at both the open source and the company levels, including the upcoming release of Restlet Framework 2.1.0, the printed version of ‘Restlet in Action’ book and the launch of a new product : APISpark!

Restlet wins Mobilize LaunchPad

Restlet is proud to be one of the 10 winners of the LaunchPad event organized by GigaOM. GigaOM is a popular research firm covering the major disruptive technologies (including cloud computing, connected life and big data) and their impact on markets. The final competition will take place on stage during their Mobilize 2012 event in San Francisco on September 20.

We will use this opportunity to launch our new APISpark online platform that we consider as a major step for our company, as important as the launch of Restlet Framework open source project in 2005, when it became the first REST framework for Java to launch!

APISpark reinvents web API development

APISpark is the first Platform as a Service (PaaS) to let you fully create, host, use and manage web APIs from a simple web browser. With an important focus on usability, it aims to be usable by any person involved in a web API project, on both the API provider side (owner, manager, developer) and on the API user side (guest, authorized user).

Existing solutions require you to either rely on a one-size-fits-all web API provided by a mobile backend vendor, or to use a low-level technical web API from an on-line database or finally to pick-up a web API development framework (such as Restlet Framework) and to combine it with a web API management solution.

With the first two solutions you loose much control and ends up with a generic web API (comparable to a CMS with a fixed set of pages). Instead, your web API should expose your domain resources with custom resources, URIs and representations. In addition, most existing solutions limits you to JSON variants, excluding other variants (such as XML, CSV or HTML) that might be required.

With the third solution, you can have full control on your web API but at the expense of a much longer development process. Then, you need to take care of its hosting and operations, maybe using a web API manager which act as an HTTP proxy, relaying API calls after control to your actual web API, introducing another layer of complexity and network latency.

APISpark innovates by radically addressing all those issues at the same time (and a few more !), using the Restlet Framework as a powerful and proven technical foundation, our ROA/D methology (covered in Appendix D of “Restlet in Action”) as a design guidelines for the user experience. Contrary to Restlet Framework, it doesn’t required strong knowledge of REST (even though it helps!) or of the Java language.

As hinted in the UI excerpt above, any web developer can use APISpark to develop and run its web API. It can take as little as 1 minute in the best case (thanks to API templates) or a few hours if you start from scratch! Using APIs published on APISpark is equally easy, with access to on-line and off-line documentation, client SDKs and built-in access management.

To learn more about APISpark, please join us at GigaOM Mobilize next month. We would be pleased to meet you personally (contact@restlet.com). If you haven’t done so yet, you can become one of the first to get access to the beta version when we launch by signing up at http://apispark.com!


Restlet Framework 2.1 RC6 and 2.0.15 released August 23, 2012

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

Moving closer to the 2.1.0 launch, we have just released two new versions : 2.1 RC6 and 2.0.15. Here is a recap of the main changes and other related news…


Versions 2.1 RC6 contain important enhancements including:

  • Improved internal HTTP connector stability
    • less CPU usage by reducing looping (using changes notification)
    • less garbage collection thanks to limitation of Iterator creation (using indexes instead)
    • some issues remain, especially for HTTPS on Windows
  • The support for HTTPS has been significantly completed and fixed in all connectors for :
    • cipher suites restriction
    • SSL/TLS protocol version restriction
    • client certificate request & requirement setting
  • Updated version of Jetty to 7.6.5 and Jackson to 1.9.8
  • Completed the JsonRepresentation class in the GWT edition for easy handling of JSON arrays, Booleans, Null and String values
  • Content negotation now respects the strict mode setting in ConnegService by returning a 406 error status

Bug fixed

In addition, version 2.0.15 fixes 12 issues on the stable branch including:

  • Concurrency bug upon application start that was especially affecting GAE in thread safe mode.
  • Content range issues.
  • Security issue that could allow JavaScript injection inside entities of error reponses.
  • Case sensitivity issue on query parameters for JAX-RS extension.

“Restlet in Action” in production

The manuscript has been fully revised and copy edited, enhancing both the content and style compared to the recent MEAP versions significantly.

The book is now in the proof reading phase and we expect the print version by mid-September!

Development of version 2.2

We have also started to work on our next version, reaching the following goals:

  • Upgraded the code base and dependencies to Java SE 6
  • Upgraded Jetty to version 8.1 (based on Servlet 3.0)
  • Upgraded Jackson to version 2.0
  • Simplified the build process and Eclipse IDE support (no more PDE/OSGi requirement to import projects)

The latest 2.2 snapshots are available for download on our web site.

In addition, we continue our efforts to refresh our online presence and are now active on Stack Overflow in addition to our traditional mailing list hosted on Tigris.org.

See the Restlet web site for additional details and please join us there as it is a compelling way to ask questions that can concern several communities such as when using Restlet on GAE with Objectify.

In addition, we have been increasingly active on Twitter. To discuss Restlet, we encourage you to use the #restlet hash tag. You can also follow us via these accounts:

  • @restlet_org for tweets related to Restlet open source project
  • @apispark for the upcoming APISpark PaaS edition of Restlet Framework
  • @jlouvel for tweets from Restlet’s creator

Finally, we are still planning to migrate the mailing list to Google Groups in the future but don’t want to disrupt too many channels at the same time…

Recent contributors

  • Abdunnassar Usman
  • Andreas Schnabl
  • Andrew Dennie
  • Bjorn Roche
  • Christian Bauer
  • Christophe Gueret
  • Danny Leshem
  • David Fuchs
  • Enoch Stephen
  • James Moger
  • Jean Duteau
  • Jim Trainor
  • Jim Zuber
  • Lukas Niemeier
  • Mark Kharitonov
  • Peter Ansell
  • Rob Heittman
  • Tim Peierls
  • Yan Zhou
  • Yunwu Zhu

Thanks to all others who helped us in various ways.

Additional resources

Changes log:

Download links:


Get every new post delivered to your Inbox.

Join 62 other followers