Category Archives: General


APISpark public beta launched

The APISpark team is happy to report the launch of its public beta. The access is no longer restricted and you can sign up today to create your first API on!

The launch was announced during the APIDays Conference (December 4th – 5th 2013) in Paris and feedback so far has been very encouraging. See this report on our participation to the event.


When signing up for APISpark, you will be able to follow tutorials to get you started and become familiar with the platform.

If you encounter any issue, you can let us know via the Help Desk so we can look into it and fix it. By doing so, you will be contributing to the successful development of APISpark and for that, we thank you.

New features and enhancements

Since our last release, we have made the following changes:

HTTPS endpoints for subdomains
We had previously announced HTTPS access to both the APISpark public web site and the console. Well, now you can also deploy your APIs safely as we have added HTTPS endpoints for all domains.

HTTPS endpoints

We also fixed SSL certificates to prevent unecessary browser warnings.

Quick export of Data Stores as Web APIs

Previously, creating a regular CRUD web API from an entity store required several steps including:

  • switching from the entity store to the dashboard
  • creating a new custom web API
  • importing the entity store from the API via the settings tab
  • launching the feature adding the resources from the store
  • switching to the API overview to see the new API contract

While this only takes five minutes to achieve, we realized that these steps are not very intuitive for new users. This is where the new API export feature really helps.

Quick export

Instead of five steps, you can now do all this in a single step! We have added an “Export custom API” action to the actions menu of entity stores (and also to file stores).

That action displays a special Web API creation wizard, right inside the store page. Once you fill out all the info and click on “Create”, you directly see the API overview of the new API.

Global ordering review

In this version, we also revamped the ordering of items displayed in the console, such as the properties of an entity and the list of resources of an API.

We now guarantee that their visual order will be maintained and will be logical as it can have some impact at runtime, for example on routing of API calls.


As you can see above, you can easily drag & drop a resource to change its order as well.

Misc changes

To ensure an efficient recovery plan, your structured data (store via the default entity stores) is now replicated 3 times in 2 regions (USA and Europe).

The next step for us it now to also replicate the web APIs and provide a cross-region deployment and availability of those APIs.

Finally, we also fixed about 18 bugs in this new release.

From all the Restlet team, we wish you Happy Holidays!

Swann Vichot

News coverage:

APISpark at APIdays Paris 2013

What an event!

First of all, let me just say that as a newbie to the API arena, I found this conference to be full of valuable information and extremely rich in content.

Api Days 2013 Paris.

There were many industry-leading speakers. Jérôme Louvel, CEO of Restlet, was a speaker for the first day of the event and had wonderful turnout for his speech “Web APIs, the New Language Frontier”. He also announced the public beta of APISpark, more details are coming in another blog post!

Api Days 2013 Paris.

If you missed it or are interested in reviewing the slides again, you can find them here:

The second and last day was a little less restless (pun intended – excuse me, as a non-tech person, this is probably the only one accessible to me!) Steve Sfartz, VP of Engineering at Restlet, gave his speech “How to Build your Web API”. There weren’t many developers in the room but we did get visits at our booth after the presentation and got valuable feedback and a very interesting use case to explore – thanks to Wenting Sun of Nanyang Technological University of Singapore.

Here are Steve and Wenting, using the APISpark platform on an iPad to build and study her API needs.

ApiDays Paris 2013

As a Gold Sponsor we were really happy with the way things were set up. There were some stimulating talks and positive energy throughout. Overall, a great success!

On a complete side note, breakfast was delicious and very français.

Thank you to Webshell and FaberNovel for organizing this great event.


by Swann Vichot
Marketing Assistant at Restlet

Thank you to APIdays and François Tancré for the photos.


Can the rise of SPDY threaten HTTP?


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!

Update 1: Mozilla – Firefox 11 is adding support for SPDY, the ball is rolling!
Update 2: ReadWriteWeb – Is Microsoft challenging Google on HTTP 2.0 with WebSocket?
Update 3: Jean Paoli (Microsoft) – Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster
Update 4: Mark Nottingham (Yahoo!) – What’s next for HTTP?