APISpark integrates with existing data stores

September 23, 2013

Posted by Jerome Louvel in : APISpark, Restlet General, Uncategorized - no comment

Summer has been hot for the APISpark team. We improved the overall platform stability, fixed more than 50 issues, and added many new features. Today, we are happy to roll out a new release in production!

Re-expose your backend as web APIs

Today, mobile and HTML 5 applications are connected. These applications rely on a cloud backend to store user and shared data. Beside the lengthy Do It Yourself (DIY) approach, many developers prefer to rely on BaaS (Backend as a Service) providers such as Parse, StackMob and Firebase.

Several developers came to us asking for an easy and flexible way to re-expose data contained in their mobile backends. Moreover, these developers want to add business value to their data through custom, domain specific Web APIs. In other words, the built-in Web API provided for free by their traditional BaaS lacks flexibility and extensibility to suit their needs.

This is where APISpark’s new “Entity Store Wrappers” come into play, providing an easy way to expose one or multiple custom API on top of an existing BaaS. Click above to follow the APISpark tutorial for each wrapper.

Turn your Google Spreadsheets into APIs

In addition, we have worked on an integration with Google Spreadsheet. This brand new wrapper helps you expose structured data while keeping the ability to edit them using your traditional spreadsheet UI. We strongly believe that this wrapper will suit a large set of user needs and specifically Open Data use cases.

Expose your Database in the Cloud as APIs

To finish with, we also added a wrapper for any JDBC data sources, such as classic relational databases as explained in this tutorial. We have plans for additional entity wrappers, so please give us feedback on the integration models you would like to see work on.

Serve your existing files stored in AWS S3

Even though APISpark already comes with built-in file stores, internally backed by AWS S3, some users want to re-expose files stored in their own AWS S3 account. Thanks to the new File Store wrapper, APISpark supports this scenario as explained in this tutorial.

Our plan is to incrementally add new wrappers. Google Drive comes next on our list.

Many more enhancements!

In addition to these new wrappers, we have added many features based on your feed-back including:

  • GWT and Android client SDKs

  • Source code export for your web APIs (based on the open source Restlet Framework)

  • Support for GitHub login and more providers

  • Subscription management (plan selection, payment, billing)

  • Deployment region can now be selected (US-West or EU-West right now)

  • Enhanced dashboard filters, full-text capabilities, instant search

  • Terms of Use and Privacy Policy pages

Next steps

If you don’t have an APISpark account yet, we invite you to sign up for the beta. And if you can’t  wait to discover APISpark, walk through our first tutorial. If you want to know what is coming next, please check our updated public roadmap.

Thanks for all your feed-back. We can’t wait to seeing what you will build with APISpark!

New release of APISpark rolled out

May 21, 2013

Posted by Jerome Louvel in : APISpark, Restlet General - no 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 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 - no comment

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

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 which is an easy way to get started. However, more advanced API projects will prefer to use their own domain name such as

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

APISpark public beta started!

February 25, 2013

Posted by Jerome Louvel in : APISpark, Restlet General - no comment

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 in Action’ book available in print

October 19, 2012

Posted by Jerome Louvel in : APISpark, Restlet, Restlet General - no comment


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

Launching APISpark at GigaOM Mobilize 2012!

August 23, 2012

Posted by Jerome Louvel in : APISpark, Restlet General - no comment

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


The battle of APIs rages for IaaS domination

June 23, 2012

Posted by Jerome Louvel in : Ecosystem, Restlet General - no comment

AWS is becoming the Windows of cloud era

Thanks to its disruptive and fast-paced innovations, Amazon has built a comprehensive and dominant IaaS stack that inspires all of us. It started first with virtualized machines (EC2) and large scale file storage (S3) and has completed its offering both horizontally (DynamoDB, Elastic MapReduce, ElasticSearch, IAM, etc.).

Many applications have tied themselves to their web APIs which are necessary to use their web services. AWS APIs have therefore become the “de facto” standard APIs for cloud computing, despite the fact that they are proprietary, lack in RESTful design and use custom security schemes.

Using AWS APIs to compete with AWS

Other infrastructure providers have been working hard to build alternatives. The first approach is simple in theory: let’s accept the AWS APIs as the current standard and try instead to provide and alternative implementation, as much compatible as possible.

Eucalyptus has been a leader on this front with its open source project, even if other providers such as Apache CloudStack and OpenStack are offering some level of compatibility as well. Eucalyptus currently provides alternative implementations for most popular AWS APIs : S3, EC2, EBS, AMI and IAM.

Even though this strategy illustrates the power of web APIs, there are several issues to keep in mind.

The API compatibility issue

The first one is that it is very hard to support all AWS APIs and then to support 100% of their features in a way that is fully portable. This difficulty is strongly pointed out by Lew Moorman, President of Rackspace, in a talk he gave at GigaOM Structure conference and further explained by Thorsten von Eicken from RightScale in this post.

The API copyright issue

Another major concern is the fact that it isn’t clear at this stage whether or not implementing those APIs respects their copyright. This question is not to be taken lightly as we can see Oracle and Google currently fighting in Court regarding the fact that Google copied the core Java APIs in order to provide an alternative implementation in Android. See this blog post from Kin Lane for details.

It is interesting to note that Eucalyptus and AWS have recently signed an agreement, that encourages the implementation of all AWS APIs which is likely a way for AWS to counter the lock-in argument that they probably face frequently. Still, this is an unstable legal position and until AWS releases those APIs in open source, that legal uncertainty will remain.

Update: a recent ruling indicates that in Android’s case, Google used Java APIs didn’t infringe on Oracle’s copyright. Thanks to J.P. Figer for the remark.

Creating alternative open source stacks

Instead of focusing on AWS APIs, OpenStack, Apache CloudStack or vmWare CloudFoundry are building open source alternatives to AWS proprietary stack, not just clones.

Below is an illustration for OpenStack, which is promoted by RackSpace and a large number of partner companies. Note that at this stage it doesn’t provide an alternative to managed databases such as AWS RDS or DynamoDB.

There is no winner yet and we’ll have to watch those projects evolve and new one emerge. While OpenStack appears to have a lot of traction, it recently saw NASA and Citrix changing strategy. NASA now promotes usage of AWS (thanks to Jean-Paul Figer for the pointer) and Citrix has bought and gave the code to Apache Foundation to initiate the CloudStack project.

Looking ahead

In the long term, some truly standard and open APIs will definitely emerge for commodity IaaS features, following the example of Atom/AtomPub experience in the blog space or the POSIX experience for file systems.

However, it is unlikely that a one size fits all solution will soon become the Linux of the cloud. It will probably take more time for things to settle down.

For now, we will live in a world of diversity, innovation and complexity, where APIs and open source infrastructure pieces coexist and fight for developers mind share and usage. Here is an example of alternative stack to AWS.

Many alternative object storages systems are competing such as Ceph, providing APIs for compatibility with S3 API, POSIX API and others such as CIFS.

The same is true for computing and image management, and especially for cloud-scale databases such as Cassandra, MongoDB, Redis and so on.

The main drawback for this diversity is the need to operate those pieces, either directly or via partners when AWS offers an all-in-one solution.


Watching this battle going on will be fun. The GigaOM Structure event that was held this week in San Francisco provided a great stage for debate and collective thinking as summarized by this series of blog posts:

If you missed it, you have a chance to catch up with the first edition of this event that will be held in Europe next October.

The road ahead, from Noelios to Restlet

February 25, 2012

Posted by Jerome Louvel in : Ecosystem, Restlet General, Uncategorized - no comment

An exciting landscape

The past few months have been intense for our company as we worked behind the scenes to prepare the next stages of our development. Thanks to the continuous adoption of REST principles, the web API market is quickly maturing and offering us new opportunities.

A few days ago, the ProgrammableWeb directory announced that the bar of 5 000 registered APIs had been reached, with an astounding growth rate.

Our current goal is to expand our activities on top of the open source Restlet Framework in order to better address the needs of this API market.

Launching soon!

More concretely, we have been building APISpark since 2010 as an innovative PaaS product offering an all-in-one platform for web APIs, from creation to hosting, using a simple web browser.

Of course, APISpark extensively leverages the Restlet Framework but aims at radically simplifying the web API experience for both developers, managers, owners and users.

We are launching the private beta in the coming weeks and are looking for a additional testers and pilot projects. To join us in this new and exciting adventure, just sign up on the web site!

Restlet is our new company name

As we wanted to focus all the company on our open source roots, by both leveraging and strengthening the “Restlet” brand, we have changed our company name from Noelios Technologies (SARL) to just Restlet (SAS).

This change has no effect on the open source project which will continue to operate as before from the web site. The company web site will be available in parallel at

As big changes don’t come alone, we have updated our visual identity and relocated to new headquarters at ESSEC Ventures, inside the beautiful CNIT building in La Défense, near Paris.

Finally, Alexis Menard, an ESSEC student in Entrepreneurship has joined our team to help us on business development aspects for a 6 months internship. Welcome Alexis!

The road ahead

Beside launching APISpark, we will keep enhancing the Restlet Framework and even expanding it into a comprehensive Restlet Platform over the coming years, including new blocks such as :

  • Restlet Studio, an Eclipse-based IDE for either model-driven or Java-driven Restlet applications development
  • Restlet Forge, an open source build forge letting developers reuse the best of our internal build tools (multi-edition, multi-distribution, etc.)
  • Restlet Apps, an open source set of highly reusable and extensible Restlet applications for common needs (RESTful search engine, etc.)
  • Restlet Cloud, an online hosting service to easily deploy your Restlet applications, from Restlet Forge, from Restlet Studio or from APISpark

For additional details, you can read chapter 11 of the “Restlet in Action” book, which is finally entering into the pre-production phase.

Seven years after Restlet launch as an open source framework, we are still excited about the potential of REST and committed to our original mission of helping you realize your web ideas… thanks to RESTful web APIs!

Restlet improves OSGi support: new edition and update site

November 9, 2011

Posted by Jerome Louvel in : Eclipse, Equinox, OSGi, Restlet, Restlet General - no 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:

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!