APISpark 2.2 released

July 9, 2014

Posted by Swann Vichot in : APISpark, Restlet Releases, Uncategorized - no comment

In light of all the summer festivities, sport events and buzzing bees, we recently released version 2.2 of APISpark. We think that’s pretty exciting as this version includes:


This new Swagger integration in APISpark lets you display the Swagger UI and embed it in your developer portal. Basically, any web API that you create using APISpark now automatically maintains and hosts an up-to-date Swagger JSON definition.

It works for manually crafted APIs as well as those generated based on APISpark data stores (such as a local Cassandra database, an external SQL database, a Google Spreadsheet, a Parse or Firebase backend). This Swagger definition is also used to produce an API Commons manifest.


We are currently working on embedding the Swagger Code Generation to provide additional high-level client SDKs (Scala, Flash, Objective-C, PHP, Python or Ruby) and server skeletons (to bootstrap manual API implementations). For now, experienced developers can manually use the open source Swagger tooling and take advantage of existing client SDKs for Java, JavaScript, Android and GWT.

Custom identifiers

Foot-long primary keys based on UUIDs are now optional. You can chose a custom pattern that makes sense for your data set. Here are some notable differences between the two that can help you choose the best alternative:

  • For POST requests:
    • in generated mode, a UUID is automatically computed,
    • in custom mode, a verification of the user provided ID is made and an error returned when existing IDs are already used.
  • For PUT requests
    • in generated mode, the request will only succeed if the ID exists,
    • in custom mode, it overrides the resource state if the ID already exists, otherwise it creates it.

Design time validation

Several validation checks have been added to the APISpark console when designing. Examples:

Error messages

You will now be prompted with a relevant message if you try to delete an element dependent on another one. This will prevent you from breaking anything without knowing about it first!

Restlet in the Press


Last month, Jerome Louvel – Restlet co-founder – became an Official Community Editor for the Web API topic. Here are the first articles he’s published:

API Evangelist

Read what Kin Lane’s been saying about Restlet and APISpark:

Disclosure: Restlet is an API Evangelist partner


Mark Boyd from ProgrammableWeb also wrote a thorough summary of all the API goodness announced during the Gluecon conference in May:

Additional resources

Learn more:
TutorialsUser guideRoad Map
A Field Guide to Web APIs by Kin Lane
PaaS Market Moves Beyond Deployment and Scaling by David Linthicum

For more updates:
Follow Restlet on Twitter (@restlet_org)

Key Quotes from Java API Copyright Case between Oracle and Google

May 17, 2014

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

After the shock wave following the recent legal decision at Federal level on the Java copyright case between Oracle and Google, I decided to read the 69 pages of the court decision and extract the most interesting quotes, from a Java technologist point of view.


US Court - Oracle vs Google

Quote 1 – Scope

This copyright dispute involves 37 packages of computer source code. The parties have often referred to these groups of computer programs, individually or collectively, as “application programming interfaces,” or API packages, but it is their content, not their name, that matters.”

Quote 2 – On patents

The jury found no patent infringement, and the patent claims are not at issue in this appeal.

Quote 3 – Java definition

The Java platform includes the “Java development kit (JDK), javac compiler, tools and utilities, runtime programs, class libraries (API packages), and the Java virtual machine.

Quote 4 – API analogy with a books library

The parties have not disputed the district court’s analogy: Oracle’s collection of API packages is like a library, each package is like a bookshelf in the library, each class is like a book on the shelf, and each method is like a how-to chapter in a book.

Quote 5 – Core Java packages

The district court found, and Oracle concedes to some extent, that three of those packages—java.lang,, and java.util—were “core” packages, meaning that programmers using the Java language had to use them “in order to make any worthwhile use of the language.”

Quote 6 – Two types of source code

Every package consists of two types of source code— what the parties call (1) declaring code; and (2) implementing code. Declaring code is the expression that identifies the prewritten function and is sometimes referred to as the “declaration” or “header.” As the district court explained, the “main point is that this header line of code introduces the method body and specifies very precisely the inputs, name and other functionality.”

Quote 7 – Android history with Java

Google acquired Android, Inc. in 2005 as part of a plan to develop a smartphone platform. Later that same year, Google and Sun began discussing the possibility of Google “taking a license to use and to adapt the entire Java platform for mobile devices.” Copyrightability Decision, 872 F. Supp. 2d at 978. They also discussed a “possible co-development partnership deal with Sun under which Java technology would become an open-source part of the Android platform, adapted for mobile devices.” Id. The parties negotiated for months but were unable to reach an agreement. The point of contention between the parties was Google’s refusal to make the implementation of its programs compatible with the Java virtual machine or interoperable with other Java programs. Because Sun/Oracle found that position to be anathema to the “write once, run anywhere” philosophy, it did not grant Google a license to use the Java API packages.

When the parties’ negotiations reached an impasse, Google decided to use the Java programming language to design its own virtual machine—the Dalvik virtual machine (“Dalvik VM”)—and “to write its own implementations for the functions in the Java API that were key to mobile devices.” Id. Google developed the Android platform, which grew to include 168 API packages—37 of which correspond to the Java API packages at issue in this appeal.

Quote 8 – SSO and the 37 Java packages at issue

With respect to the 37 packages at issue, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.” Id. To achieve this result, Google copied the declaring source code from the 37 Java API packages verbatim, inserting that code into parts of its Android software. In doing so, Google copied the elaborately organized taxonomy of all the names of methods, classes, interfaces, and packages— the “overall system of organized names—covering 37 packages, with over six hundred classes, with over six thousand methods.” Copyrightability Decision, 872 F. Supp. 2d at 999. The parties and district court referred to this taxonomy of expressions as the “structure, sequence, and organization” or “SSO” of the 37 packages. It is undisputed, however, that Google wrote its own implementing code, except with respect to: (1) the rangeCheck function, which consisted of nine lines of code; and (2) eight decompiled security files.

Quote 9 – Android incompatibility with Java

Although Android uses the Java programming language, it is undisputed that Android is not generally Java compatible. As Oracle explains, “Google ultimately designed Android to be incompatible with the Java platform, so that apps written for one will not work on the other.”

Quote 10 – Java interoperability and command structure

According to Google, however, the district court correctly determined that: (1) there was only one way to write the Java method declarations and remain “interoperable” with Java; and (2) the organization and structure of the 37 Java API packages is a “command structure” excluded from copyright protection under Section 102(b). Google also argues that, if we reverse the district court’s copyrightability determination, we should direct the district court to retry its fair use defense.

Quote 11 – Decision on copyrightability

The court also erred by importing fair use principles, including interoperability concerns, into its copyrightability analysis. For the reasons that follow, we conclude that the declaring code and the structure, sequence, and organization of the 37 Java API packages are entitled to copyright protection.

Quote 12 – Java API design was a creative process

The testimony at trial revealed that designing the Java API packages was a creative process and that the Sun/Oracle developers had a vast range of options for the structure and organization. In its copyrightability decision, the district court specifically found that the API packages are both creative and original, and Google concedes on appeal that the originality requirements are met.

Quote 13 – Is an API just an idea and the implementation its expression?

In its analysis, the court identified the method declaration as the idea and found that the implementation is the expression. Id. (“The method specification is the idea. The method implementation is the expression. No one may monopolize the idea.”) (emphases in original). The court explained that, under the rules of Java, a programmer must use the identical “declaration or method header lines” to “declare a method specifying the same functionality.”

Quote 14 – Two years to write the core Java packages

it took years to write some of the Java packages and that Sun/Oracle developers had to “wrestle with what functions to include in the package, which to put in other packages, and which to omit entirely”).

Quote 15 – Interoperability doesn’t relate to copyrightability, but to fair user

Oracle also argues that the district court erred in invoking interoperability in its copyrightability analysis. Specifically, Oracle argues that Google’s interoperability arguments are only relevant, if at all, to fair use—not to the question of whether the API packages are copyrightable. We agree.

Quote 16 – Java interoperability was not the real aim of Google with Android

Google maintains on appeal that its use of the “Java class and method names and declarations was ‘the only and essential means’ of achieving a degree of interoperability with existing programs written in the [Java language].” Appellee Br. 49. Indeed, given the record evidence that Google designed Android so that it would not be compatible with the Java platform, or the JVM specifically, we find Google’s interoperability argument confusing. While Google repeatedly cites to the district court’s finding that Google had to copy the packages so that an app written in Java could run on Android, it cites to no evidence in the record that any such app exists and points to no Java apps that either pre-dated or post-dated Android that could run on the Android platform.

Quote 17 – Google wanted to capitalize on trained Java developers

The compatibility Google sought to foster was not with Oracle’s Java platform or with the JVM central to that platform. Instead, Google wanted to capitalize on the fact that software developers were already trained and experienced in using the Java API packages at issue. The district court agreed, finding that, as to the 37 Java API packages, “Google believed Java application programmers would want to find the same 37 sets of functionalities in the new Android system callable by the same names as used in Java.”

Quote 18 – Irrelevant argument of Java as an industry standard

Google was free to develop its own API packages and to “lobby” programmers to adopt them. Instead, it chose to copy Oracle’s declaring code and the SSO to capitalize on the preexisting community of programmers who were accustomed to using the Java API packages. That desire has nothing to do with copyrightability. For these reasons, we find that Google’s industry standard argument has no bearing on the copyrightability of Oracle’s work.

Quote 19 – Fair use  factors

“Section 107 requires a case-by-case determination whether a particular use is fair, and the statute notes four nonexclusive factors to be considered.” [...] Those factors are: (1) “the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;” (2) “the nature of the copyrighted work;” (3) “the amount and substantiality of the portion used in relation to the copyrighted work as a whole;” and (4) “the effect of the use upon the potential market for or value of the copyrighted work.”

Quote 19 – Fair use defense from Google

Google contends, however, that, although it admittedly copied portions of the API packages and did so for what were purely commercial purposes, a reasonable juror still could find that: (1) Google’s use was transformative; (2) the Java API packages are entitled only to weak protection; (3) Google’s use was necessary to work within a language that had become an industry standard; and (4) the market impact on Oracle was not substantial.

Quote 20 – New trial on fair use question

On balance, we find that due respect for the limit of our appellate function requires that we remand the fair use question for a new trial. First, although it is undisputed that Google’s use of the API packages is commercial, the parties disagree on whether its use is “transformative.”

Quote 21 – Google transformative argument and Oracle’s defense

Google argues that it is, because it wrote its own implementing code, created its own virtual machine, and incorporated the packages into a smartphone platform. For its part, Oracle maintains that Google’s use is not transformative because: (1) “[t]he same code in Android . . . enables programmers to invoke the same pre-programmed functions in exactly the same way;” and (2) Google’s use of the declaring code and packages does not serve a different function from Java.

Quote 22 – Inability to decide on fair use

While Google overstates what activities can be deemed transformative under a correct application of the law, we cannot say that there are no material facts in dispute on the question of whether Google’s use is “transformative,” even under a correct reading of the law. As such, we are unable to resolve this issue on appeal.

Quote 23 – Importance of Java core packages for fair use retrial

We find this particularly true with respect to those core packages which it seems may be necessary for anyone to copy if they are to write programs in the Java language. And, it may be that others of the packages were similarly essential components of any Java language-based program. So far, that type of filtration analysis has not occurred.

Additional references

Restlet Framework 2.2.1 and 2.3 M2 released

May 6, 2014

Posted by Swann Vichot in : Restlet Releases, Uncategorized - no comment

We are happy to announce the release of two Restlet Framework versions:
2.3 M2 and 2.2.1. We also made changes on website, covering the web API platform, including of course the open source Restlet Framework and the related APISpark PaaS as well.

Please feel free to comment below if you have suggestions for the website. Are there any sections you would like us to focus on? Are the answers to your questions easy to find? Any feedback is welcome!


What’s new?

Version 2.3 M2 (testing)

Automated documentation via APISpark
The extension for APISpark now includes an Introspector tool that can analyze your existing Restlet Application (no modification required), extract its web API definition and push it to for online and intuitive documentation.

integration AS and RF_3Your web API documentation on APISpark can be set as either public or private. We will quickly expand support to add full API management support including:

  • Auto-generated client SDKs
  • User management
  • IP blocking and rate limitation
  • Usage reports

Learn more by reading the APISpark extension page in Restlet user guide.



  • Added HTTPS support to Jetty 9.1 connector. Next we’ll add SPDY support
  • ServletWarEntity and ZipEntryEntity ignore the timeToLive parameter
  • ServletWarEntity isn’t limited anymore to file system modification dates

Bug fixed

  • Added copy of Servlet request parameters to the Restlet request attributes
  • Stripped Servlet container generated “jsessionid” matrix parameter
  • All bugs fixed in 2.2.1 (see below)


  • Removed unnecessary “.properties” files from the distributions
  • Added mention of edition and version in Javadoc header
  • Lowered trace level from ‘info’ to ‘fine’ for OBAP pseudo client

What’s coming next? Check out our updated road map.


Version 2.2.1 (stable)

Bug fixed

  • Fixed missing internal FTP client and HTTPS server connector registration.
  • Removed extra console traces left by mistake.
  • Fixed missing default values for DefaultSslContextFactory attributes.
  • Removed unnecessary “.properties” files from the distributions.
  • Prevented NPE in org.httpclient.internal.HttpMethodCall.getStatusCode.
  • Fixed CompositeHelper.handle fails when Component has no inbound filters.
  • Stabilized Swagger documentation for JAX-RS applications.

Recent contributors

  • Claus Ibsen
  • Emanuele Massara
  • Jeremy Gustie
  • Jiri Ramte
  • Roy Olsen
  • Steve Rowe
  • Tal Liron

Thanks to all others who helped us in various ways.

Additional resources

Changes log:

Download links:

Learn more:
TutorialUser guideJavadocs
A Field Guide to Web APIs by Kin Lane

For more updates:
Follow Restlet Framework on Twitter (@restlet_org)

API Commons integration in APISpark

May 6, 2014

Posted by Swann Vichot in : APISpark, Restlet General - no comment

Today we are really happy to announce the integration of API Commons into the APISpark platform. The integration specs are explained further below, but for those who aren’t familiar with the project, here’s a little more details!


The API Commons initiative was started by Kin Lane, API Evangelist, and Steven Wilmott, CEO at 3SCale.

Kin Lane explains what led him to launch this initiative in a recent InfoQ article:

We both felt like there should be a place where API providers could publish the API designs, defined using emerging API definition formats like API Blueprint, RAML and Swagger, and take a stance on the copyright of their API design, using the Creative Commons license of their choice.

He added:

We feel strongly that API designs should remain openly licensed, allowing for re-use of the best API patterns available today. People tend to emulate what they see, and without common patterns, providers tend to reinvent the wheel each time. In 2014, you should have common patterns for calendars, directories, images, videos and other resources we depend on every day for personal and business apps.


APISpark support

With this integration, APISpark lets you define copyright and licensing metadata and automatically generates your API Commons manifest including your API definition based on Swagger specification.

Click on the image below to enlarge it.

API Commons preview

This saves you time and allows you to quickly share your API design in the commons.

In the coming weeks, we plan to introduce the following enhancements:

  • Easier selection of predefined API licenses (Creative Commons and popular Open Source ones)
  • Automated publication of your API manifest into API Commons (using their web API)

Stay tuned!


See other APISpark 2.1 enhancements.

Follow-up: importance of API Commons underlined after the new ruling in Oracle vs Google case

APISpark 2.1 released

May 6, 2014

Posted by Swann Vichot in : APISpark, Google, Restlet General - no comment

The sun is shining, Summer is approaching and it’s time to share all the cool stuff we’ve added in this APISpark 2.1 release!

Improved Google Spreadsheet Wrapper

A lot of work was done on stabilizing the wrappers and improving the tutorials. One that we think you will find interesting is Turn your Google Spreadsheet into a custom web API. You have to admit it sounds pretty cool!

GSheet Tutorial_2

This tutorial will guide you through creating an API directly from one of your Google Spreadsheet. Give it a go, it’s quite simple! Let us know what you think by commenting below or sending us an email.

API Commons Support

API Commons objective is to “provide a simple and transparent mechanism for the copyright free sharing and collaborative design of API specifications, interfaces and data models.” 


So for this release, we thought it would be great to support API Commons out-of-the box. Here is a preview of the integration in the APISpark Console:

API Commons preview

With this integration, APISpark lets you define copyright and licensing metadata and automatically generates your API Commons manifest including your API definition based on Swagger specification. This saves you time and allows you to quickly share your API design in the commons.

Sign up now to try it out!

Document your Restlet web API

Have you been using the Restlet Framework to build you API?

integration AS and RF_3

Now you can use APISpark to provide you with always up-to-date documentation. The integration has been added to the recent Restlet Framework release. Download 2.3 M2 now.

We will continue to enhance this integration to support not only Restlet API but also JAX-RS API and others, generate client SDKs, manage users and prepare usage reports for all your existing web APIs!

Read the APISpark page in Restlet user guide for details. Don’t forget to give us your feedback so we can make a product better suited to you!


Additional resources

Learn more:
TutorialsUser guideCatalog
A Field Guide to Web APIs by Kin Lane
PaaS Market Moves Beyond Deployment and Scaling by David Linthicum

For more updates:
Follow APISpark on Twitter (@apispark)

PaaS Market Moves Beyond Deployment and Scaling

May 2, 2014

Posted by Swann Vichot in : General, Restlet General - no comment

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

DavidLinthicumFollow David on Twitter

Following are the summary and a few extracts of the report. Download the full electronic version here.


Table of contents

  • Executive Summary
  • State of the PaaS Market
  • While PaaS is Lagging Behind IaaS
  • Intersection with the API management
  • Backend-as-a-Service and Database-as-a-Service markets
  • Where the API market is headed – Netflix case study
  • How could PaaS be specialized and leverage web APIs in a way similar to IaaS?
  • Key takeaways


“PaaS is not only about deploying and scaling apps using APIs but also about creating, testing, and debugging those applications, as well as mashing together different web APIs to create new applications for business users.”

“Web APIs are emerging as the best path to provide customized and critical functionality to applications.”




“The demands from the developer seem to be changing. Many now ask for an easy and flexible way to re-expose data contained in their mobile backends. [...] What we need is a way to combine the value of BaaS and DBaaS into a single API framework that can be extended, as required, by the application.”

“Netflix has been moving from the more traditional one-size-fits-all approach to leveraging APIs, such as the use of BaaS, to a custom web API approach where Netflix is, in essence, providing a platform to build APIs that fit the exact needs of the user.”

“Solutions are emerging, such as APISpark, that connect existing or new data sources and then generate web APIs. [...] Cloud API deployment from common data sources is making API development and deployment quick and easy.”


“Web APIs are emerging as the best path to provide customized and critical functionality to applications, including those built within PaaS systems. By providing the functional equivalent to a PaaS-based API development platform, we provide the ability to create, deploy, and manage APIs as a Service, out of the cloud.”

Read the report and let us know what you think by commenting below. Download the full electronic version here.


The research report was underwritten by Restlet.

OpenSSL Security Update / Heartbleed

April 9, 2014

Posted by Swann Vichot in : APISpark, Restlet General, Security - no comment

A major OpenSSL vulnerability was revealed yesterday. Learn more about the Heartbleed Bug.

The Restlet Operations team immediately started analyzing its implications: our AWS Elastic Load Balancers (ELB) used for APISpark were our main infrastructure component at risk.

APISpark Logo

Amazon has now fully fixed its ELBs and communicated the procedure for their customers to renew the SSL certificates. We have now completed the renewal of our SSL certificates for both and

Logo - Restlet Framework

Regarding the Restlet Framework itself, as it relies on the Java Virtual Machine which includes its own SSL security implementation not related to OpenSSL, it isn’t directly affected.

However, be aware that some Java EE application servers such as Tomcat or JBoss allow you to use a native SSL implementation based on OpenSSL, so please make sure to double check how your Restlet applications are deployed and run in production.

Sometimes, SSL encryption is terminated before your Restlet application (such as for APISpark), so you might still be vulnerable in a higher layer.

If you have any question or concern, don’t hesitate to contact us via email.

Restlet Framework 2.2.0 and 2.3 M1 released!

March 27, 2014

Posted by Swann Vichot in : Restlet Releases, Uncategorized - no comment

It’s been a year and a half since the 2.1.0 release of the Restlet Framework so we are proud to announce the release version 2.2.0!

In 2013 we were also very busy with the development of APISpark, our new cloud platform for web APIs based on the framework. Actually, we recently released APISpark 2.0 so feel free to try it out, there’s lots to explore!

What’s new?

Let’s step back and review the major changes introduced since version 2.1. For complete details, you can consult the related changes log.


  • Java 6 foundation
  • Apache License 2.0
  • Internal HTTP client and server now based on JDK Net classes
    • reduced size by 45Kb for org.restlet.jar
    • recommended Android HTTP client by Google
    • moved previous internal connector to new NIO extension
  • Added Guice extension, Google’s dependency injection library
  • Added Swagger extension (only JAX-RS API support for now)
  • Added Thymeleaf extension for templating
  • Added GSON extension, supporting Google’s JSON serialization library
  • Added HTTP PATCH method support
  • Added JSONP filter to workaround single origin policies in browsers
  • Updated Jackson extension to support additional media types
    • JSON, Smile (JSON binary), XML, YAML and CSV
  • Updated OAuth extension to final 2.0 RFC (preview)
    • added client support for HTTP OAuth MAC authentication
  • Updated JAX-RS extension with client support (not JAX-RS 2.0 based)
  • Updated OSGi extension with inter-bundle OBAP:// pseudo-protocol
  • Revamped User Guide with easier navigation and content update
    • most broken links due to Daisy wiki migration were fixed
    • “Edit” button linked to GitHub for easy maintenance
  • Converter exceptions are now properly transmitted
  • Added Javadocs artefacts to Maven repository
  • Updated over 25 dependencies (Jackson, Jetty, Apache HTTP Client)
  • Many bug fixes


Early in the 2.2 development, we also:

  • Redesigned Restlet Framework logo and web site
  • Migrated forge to GitHub for source code, issues tracker and devs wiki
  • Made contributions easier as modules are now regular Eclipse projects
  • Increased user questions answers via StackOverflow

What’s coming next?

Here’s a sneak peak of the enhancements coming in version 2.3. You can download the new version 2.3 M1 here.

  • Java 7 foundation
  • Web API documentation and management
    • based on APISpark and Swagger
    • supporting various API description languages
    • introspecting various Java APIs for REST
  • Jetty 9.1 (SPDY, HTTP client)
  • Restlet API refactorings and enhancements
  • JAX-RS 2.0 support (via RESTEasy embedding)
  • Mailing lists migration to Google Groups
  • Improved user guide and new tutorial

Check out the complete 2.3 road map here.

Major contributors

Thanks to all contributors including Abraham Kang, Alvaro Munoz, Andy Dennie, Bobby Sawhney, Brian Sletten, Carl J. Mosca, Cyril Lakech, Daniel Halperin, David Jorm, David Roussel, Dennis Mitchell, Dinis Cruz, Emmanuel Liossis, Florian Bucklers, Grzegorz Godlewski, Koen Maes, Ioan Lupu, Jason Guild, Jeff Plourde, Laurent Rustuel, Loïc Oudot, Luke Adams, Mark Kharitonov, Martin Grohmann, Martin Svensson, Neal Mi, Neha Saini, Nicolas Rinaudo, Peter Ansell, Ralph van Etten, Reddy Lakshman, Robert Fischer, Shaun Elliott, Shotaro Uchida, Tal Liron, Tim Peierls, Xiaoping Feng, Yan Pujante and Wei Wei Wang.

All your contributions made a big difference!

Additional resources

Changes log:

Download links:

Learn more:
Tutorial, User guide, Javadocs
A Field Guide to Web APIs by Kin Lane

For more updates:
Follow Restlet Framework on Twitter (@restlet_org)

APISpark 2.0 released

March 11, 2014

Posted by Swann Vichot in : APISpark, Restlet General - no comment

First of all we are very happy to announce that our website has undergone a major redesign!

It’s clearer, easier to navigate and we’ve merged and so you can find everything on the same site!

Screen Shot 2014-03-06 at 5.34.01 PM

Concerning the platform itself, a great deal of work has gone towards stabilizing the console.

Since last release in December, there have been numerous bug fixes (more than 100) in addition to several enhancements to keep our beta testers buzzing! Below is a detailed summary:

New features

  • API firewall (preview)
    • introduced IP addresses filtering with white & black lists
    • default CORS support to allow cross origin browser access
    • coming next: rate limitation
  • GitHub wrapper (preview)
    • provides a File Store wrapper backed by GitHub repositories
    • coming next: subfolders, account pairing and branch selection



  • Entity Store browser
    • auto-generated fields are hidden at creation and update time
    • 1-1 and 1-n cardinalities are supported for both primitive properties and properties referencing other entities
    • bug fixes for default values, duplicate properties and date entry (MM/dd/yyyy format enforced)

add entity from browser5

  • Error pages:
    • more explicit messages displayed
    • redirection after re-authentication in case of session expiration
  • Domain selection:
    • clearer error message in case of unavailability or forbidden characters

error messages

  • Entity Store:
    • added min/max values, auto-generated and nullable properties
    • default primary key was renamed to “id” (was “_id” before)
    • new auto-generated properties (creator, lastUpdated, created)
    • properties constraints now enforced at insertion and update time

new entity properties3

  • Web API:
    • fixed date entry issue (MM/dd/yyyy format enforced)
    • improved properties ordering for representation samples

Thank you to all our beta testers who have taken the time to give us feedback and who have supported us from the start. We hope you enjoy this new version of APISpark. Let us know what you think by sending us an email or by using the Help Desk.

APISpark 2.1 sneak peek?

For the next release, the console will be following in the footsteps of the web site start getting a complete makeover. Stay tuned!

Stay in Touch:

twitter icon orange small     google+ icon orange small     slideshare icon orange small     wordpress icon orange small     linkedin icon orange small

Restlet Framework 2.1.7 and 2.2 RC1 released

February 13, 2014

Posted by Swann Vichot in : Restlet Releases, Uncategorized - no comment

We are happy to release two new Restlet Framework versions: 2.2 RC1 and 2.1.7, quickly moving forward towards version 2.2.0 and beginning work on the 3.0 branch. Check out the updated road map for details.

Don’t forget to download A Field Guide to Web APIs from Kin Lane, API Evangelist. It’s a comprehensive developer guide, covering history of web APIs, technology used, cloud trends etc. If you want a preview before downloading the full guide, check out our previous blog post.

What’s new?

2.1 branch (stable)

Since announcing the release of the 2.1.4, we fixed several issues including:

  • XML External Entity injection security fix (please read our technical note and upgrade)
  • Generation of HTML representation of a WADL document
  • Complete the content-type header with the right boundary parameter value when using multipart representations
  • Status reason phrase set by the Jetty connector
  • Service-Component header missing in for Servlet extension in OSGi edition
  • OData not passing null when property not marked nullable
  • EncoderService exposes lists of ignored and accepted media types
  • Base64 characters padding to encoded MD5 hash before decoding.

In terms of enhancements, we added:

  • Support of nowrap “deflater” (support of GZIP compatible compression)
  • Ability to override Accept-encoding header values
  • WritableSocketChannel write loop to ensure all data has been written

Logo Restlet Framework

2.2 branch (testing)

In addition to the 2.1 branch fixes, we also solved six bugs including:

  • Declaration of Gson’s maven artifact identifier
  • Android ICS and HttpUrlConnectionCall.getResponseHeaders
  • The @Patch annotation was ignored

As well as numerous enhancements:

  • Updated over 25 dependencies (Jetty, Apache, MongoDB, etc.)
  • Added a Message#bufferEntity() method
  • Moved BufferingRepresentation from Engine to org.restlet.representation package
  • Added client support for HTTP OAuth MAC authentication
  • Added Javadocs artefacts for Maven repository
  • Added Thymeleaf templating extension
  • Improved ServerServlet.createComponent()
  • Added Swagger extension (only JAX-RS API support for now)

And made the following changes to Restlet Core (API and Engine):

  • Added new internal HTTP/HTTPS server connectors based on the package available in JDK 6
  • Moved HTTP/HTTPS/FTP client connectors into the core org.restlet module ( package) as the new internal client connectors
  • Moved NIO-based internal connector to new org.restlet.ext.nio extension. Marked as “developer preview” state.
  • Moved org.restlet.ext.ssl into core org.restlet.engine.ssl package except classes related to the jSSLutils library now part of new org.restlet.ext.jsslutils extension and for CertificateAuthenticator class now in
  • Deprecated MediaType#APPLICATION_RDF_TURTLE and added TEXT_TURTLE constant

Recent contributors

  • Alvaro Munoz
  • Andy Dennie
  • Bobby Sawhney
  • Carl J. Mosca
  • David Roussel
  • Grzegorz Godlewski
  • Ioan Lupu
  • Jason Guild
  • Luke Adams
  • Peter Ansell
  • Ralph van Etten
  • Tal Liron
  • Xiaoping Feng

Thanks to all others who helped us in various ways.

Additional resources

Changes log:

Download links:

Learn more:
Tutorial, User guide, Javadocs
A Field Guide to Web APIs by Kin Lane

For more updates:
Follow Restlet Framework on Twitter (@restlet_org)