We’re excited to announce that APISpark has just won the DataWeek + API World 2014 award for Most Innovative API Infrastructure Solution! APISpark was selected by crowd vote, where thousands of DevNetwork community members voted on the top Data + API technologies of 2014. Continue reading
New weekly competition alert!
Win prizes worth up to $250.
Sparky, our APISpark mascot, is already on his way to the API Strategy & Practice conference in Chicago and is sending us some pics along the way. Help us find him in these pics using your API skills! Continue reading
David Linthicum is an internationally known cloud computing visionary, technology innovator, and agent of change. He has been working with GigaOM Research for several years now. In this report, he puts the spotlight on the PaaS market connections with web APIs, BaaS (Backend as a Service) and DBaaS (DataBase as a Service). Continue reading
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 APISpark.com!
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 APISpark.net 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 APISpark.net domains.
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.
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.
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!
- ProgrammableWeb, Mark Boyd
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.
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!
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.
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.
- Mark Boyd (ProgrammableWeb) – Initial themes at APIDays Paris: Reuse and Cross-region
- Mark Boyd (ProgrammableWeb) – Web API language development is moving forward
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.
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.
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).
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!
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?