jump to navigation

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

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

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.

REST & Web API

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.

Follow-up:

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:
http://restlet.org/learn/2.1/changes
http://restlet.org/learn/2.2/changes

Download links:
http://restlet.org/download/

APISpark public beta started! February 25, 2013

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

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.

apispark-support-logo

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.

java-6

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

oauth2.0

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:
http://www.restlet.org/documentation/2.1/jse/changes
http://www.restlet.org/documentation/2.2/jse/changes

Download links:
http://www.restlet.org/downloads/

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

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

Preface

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

appendixes

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

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

Engine

  • 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

Extensions

  • 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

Editions

  • 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:
http://www.restlet.org/documentation/2.1/jse/changes

Download links:
http://www.restlet.org/downloads/

Launching APISpark at GigaOM Mobilize 2012! August 23, 2012

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

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!

Update:

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…

Enhancements

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:
http://www.restlet.org/documentation/2.0/jse/changes
http://www.restlet.org/documentation/2.1/jse/changes

Download links:
http://www.restlet.org/downloads/

The battle of APIs rages for IaaS domination June 23, 2012

Posted by Jerome Louvel in Ecosystem, Restlet General.
add a 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 Cloud.com 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.

Conclusion

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.

Follow

Get every new post delivered to your Inbox.

Join 62 other followers