Restlet Framework 2.1.0 released! September 27, 2012Posted by Jerome Louvel in Restlet Releases.
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 !!
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.
- 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
- 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
- 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
- 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:
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!
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!
Jérôme Louvel – Founder and lead developer
ThierryBoileau – Community manager and core developer
Thierry Templier – Core developer
Launching APISpark at GigaOM Mobilize 2012! August 23, 2012Posted by Jerome Louvel in APISpark, Restlet General.
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 (email@example.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!
- DailyMotion – Video recording of our launch including the feed-back from the VCs panel
- Some pictures below (thanks to Sébastien Rouif)
Restlet Framework 2.1 RC6 and 2.0.15 released August 23, 2012Posted 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…
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
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.
- 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…
- 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.
The battle of APIs rages for IaaS domination June 23, 2012Posted 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
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.
In the long term, some truly standard and open APIs will definitely emerge for commodity IaaS features, following the example of Atom/AtomPub experience in the blog space or the POSIX experience for file systems.
However, it is unlikely that a one size fits all solution will soon become the Linux of the cloud. It will probably take more time for things to settle down.
For now, we will live in a world of diversity, innovation and complexity, where APIs and open source infrastructure pieces coexist and fight for developers mind share and usage. Here is an example of alternative stack to AWS.
Many alternative object storages systems are competing such as Ceph, providing APIs for compatibility with S3 API, POSIX API and others such as CIFS.
The same is true for computing and image management, and especially for cloud-scale databases such as Cassandra, MongoDB, Redis and so on.
The main drawback for this diversity is the need to operate those pieces, either directly or via partners when AWS offers an all-in-one solution.
Watching this battle going on will be fun. The GigaOM Structure event that was held this week in San Francisco provided a great stage for debate and collective thinking as summarized by this series of blog posts:
- If AWS is the Walmart of cloud, is OpenStack the Soviet Union?
- The Amazon API battle for the cloud rages on
- Amazon’s Werner Vogels on next 5 years of cloud
- Wired – Cloning Amazon Is a Dead End, Says Cloud Rival Rackspace
- GigaOM Pro - Mapping Session results: IaaS endgame
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.
Restlet Framework 2.1 RC5 and 2.0.14 released May 23, 2012Posted by Jerome Louvel in Build, Restlet Releases.
add a comment
Since the last blog post related to releases in February, we have pushed a couple of new versions, including 2.1 RC5 and 2.0.14 today. It’s time to recap a little about the changes they bring and other important news…
Versions 2.1 RC4 and RC5 contain minor enhancements including:
- Support for URI templates on the client-side
- Improved internal HTTP connector (chunked encoding and SSL)
- Added syntactic sugar on Resource, ClientResource and ServerResource
- getAttribute(name), getQueryValue(name), getMatrixValue(name) and equivalent setters
- accept(…) for easier content negotiation
- setProxyChallengeRequest(..), setProxyChallengeResponse(…)
- Added CertificateAuthenticator to SSL extension
In addition, version 2.0.14 fixes 16 issues on the stable branch including:
- Security issue in the XML extension related to XML entities
- OutputRepresentation issue with binary data causing early end of file
- User agent name detection for Firefox on Windows
- Content negotiation, multiple cookies and interface introspection issues with JAX-RS extension
Also, versions 2.1 RC4 and RC5 contain 22 bug fixes.
“Restlet in Action” in pre-production
We have continued working hard on our book, benefiting from a great technical proofing work done by Tim Peierls and on the constant feed-back of readers in the book forum. The manuscript is now complete, with all chapters and appendices available in early access. We have also refined the first six chapters and led them into the pre-production stage.
We recently made significant enhancements to the security chapter (n°5) to add more complete and reusable sample code and to better connect it with surrounding chapters, listening to the feed-back of several readers. We still have a busy work schedule for the summer, but should be able to put our hands on the printed version around September or soon after!
Development of version 2.2
After migrating our code base to GitHub, we have done the same for our issues tracker, adding cross-references for existing issues. If you need to report bugs or enhancements requests, please only use GitHub from now on. We have also started using their wiki area as a replacement for our developers wiki currently using Daisy and will complete the migration of the next few months. Next steps are the migration of the mailing list to Google Groups and StackOverflow.
We have also complete the upgrade to Java 6 which will be the minimum requirement as Java 5 has been phased out, which allowed us to remove some dependencies and libraries. We have also clarified the build process, now relying solely on Ant to generate the editions and build them. Building from Eclipse is also simplified, not requiring PDE/OSGi anymore.
- Alessandro Pacifici
- Anca Luca
- Andrei Pozolotin
- Andy Dennie
- Arjohn Kampman
- Bjorn Roche
- Bruno Harbulot
- Fabio Mancinelli
- Gabriel Pulido
- Grzegorz Godlewski
- Jean-Baptiste Dusseaut
- John Logsdon
- Laszlo Hordos
- Marc Knaup
- Martin Svensson
- Michael Henderson
- Nicholas Waltham
- Shaun Elliott
- Thomas Mortagne
- Tim Peierls
- Vincent Massol
Thanks to all others who helped us in various ways.
Restlet Framework 2.1 RC3 and 2.0.11 February 25, 2012Posted by Jerome Louvel in Restlet Releases, Uncategorized.
Since the last release related post in October, we have released 2.1 RC2, 2.0.11 and more recently 2.1 RC3. It’s time to recap a little about the changes they bring and other important news…
Migration to GitHub
After thinking about it for a while, active voices in Restlet community such as Andrei Pozolotin, Bryan Hunt and Xavier Bourguignon, convinced us to move our code repository to the highly popular GitHub platform.
This wasn’t an easy change as we had to import our large SVN code base, including doing proper branch and tag mapping from one system to another, and updating our build process.
Next steps will be the migration of tickets to GitHub and of the mailing list to Google Groups and StackOverflow.
By the time we release version 2.1.0, we will hopefully be running our open source project on a state-of-the-art infrastructure!
Apache License 2.0
In addition to the other licensing options you can already choose from, including LGPL 2.1/3.0, CDDL 1.0 and EPL 1.0, we have recently added a new popular option: the Apache License 2.0.
This new option also confirms a deep commitment to our open source roots at a moment where we rename our company to Restlet (SAS) and are about to launch new products on top of the Restlet Framework as explained in this other blog post: The road ahead, from Noelios to Restlet.
In addition, version 2.0.11 fixes 5 issues on the stable branch including:
- MediaType.includes side effect
- OData client performance
- GWT support of HTTP BASIC authentication
- Conversion issues with annotated interfaces
Also, version 2.1 RC 3 contains 7 bug fixes including:
- JAX-RS introspection of parent classes
- Made usage of raw HTTP credentials easier
In addition, version 2.1 RC 3 contain minor enhancements summarized below:
- Added Restlet API syntaxic sugar
- Added ByteArrayRepresentation
- Updated Jettison to version 1.3
- Updated XStream to version 1.4.1
- Alex Milowski
- Arjohn Kampman
- Bill Claypool
- Bryan Hunt
- Dejan Lozanovic
- Jean-Baptiste Dusseaut
- Jerome Idylle
- John Logdson
- Klaus-Peter Schlotter
- Koen Maes
- Kristoffer Gronowski
- Nikhil Purushe
- Shaun Elliott
- Try Lam
Thanks to all others who helped us in various ways.
The road ahead, from Noelios to Restlet February 25, 2012Posted by Jerome Louvel in Ecosystem, Restlet General, Uncategorized.
An exciting landscape
The past few months have been intense for our company as we worked behind the scenes to prepare the next stages of our development. Thanks to the continuous adoption of REST principles, the web API market is quickly maturing and offering us new opportunities.
A few days ago, the ProgrammableWeb directory announced that the bar of 5 000 registered APIs had been reached, with an astounding growth rate.
Our current goal is to expand our activities on top of the open source Restlet Framework in order to better address the needs of this API market.
Launching APISpark.com soon!
More concretely, we have been building APISpark since 2010 as an innovative PaaS product offering an all-in-one platform for web APIs, from creation to hosting, using a simple web browser.
Of course, APISpark extensively leverages the Restlet Framework but aims at radically simplifying the web API experience for both developers, managers, owners and users.
We are launching the private beta in the coming weeks and are looking for a additional testers and pilot projects. To join us in this new and exciting adventure, just sign up on the http://apispark.com web site!
Restlet is our new company name
As we wanted to focus all the company on our open source roots, by both leveraging and strengthening the “Restlet” brand, we have changed our company name from Noelios Technologies (SARL) to just Restlet (SAS).
This change has no effect on the open source project which will continue to operate as before from the http://www.restlet.org web site. The company web site will be available in parallel at http://www.restlet.com.
As big changes don’t come alone, we have updated our visual identity and relocated to new headquarters at ESSEC Ventures, inside the beautiful CNIT building in La Défense, near Paris.
Finally, Alexis Menard, an ESSEC student in Entrepreneurship has joined our team to help us on business development aspects for a 6 months internship. Welcome Alexis!
The road ahead
Beside launching APISpark, we will keep enhancing the Restlet Framework and even expanding it into a comprehensive Restlet Platform over the coming years, including new blocks such as :
- Restlet Studio, an Eclipse-based IDE for either model-driven or Java-driven Restlet applications development
- Restlet Forge, an open source build forge letting developers reuse the best of our internal build tools (multi-edition, multi-distribution, etc.)
- Restlet Apps, an open source set of highly reusable and extensible Restlet applications for common needs (RESTful search engine, etc.)
- Restlet Cloud, an online hosting service to easily deploy your Restlet applications, from Restlet Forge, from Restlet Studio or from APISpark
For additional details, you can read chapter 11 of the “Restlet in Action” book, which is finally entering into the pre-production phase.
Seven years after Restlet launch as an open source framework, we are still excited about the potential of REST and committed to our original mission of helping you realize your web ideas… thanks to RESTful web APIs!
Restlet improves OSGi support: new edition and update site November 9, 2011Posted by Jerome Louvel in Eclipse, Equinox, OSGi, Restlet, Restlet General.
While OSGi has been for a long time an important deployment environment for Restlet developers, including an innovative project lead by NASA JPL, we have seen a surge of interest in the recent years.
The rise of REST, the addition of an Eclipse Public License option to Restlet and an increased effort from Restlet community is starting to bring new fruits!
Edition for OSGi Environments
Since version 1.1, Restlet has always tried to be friendly to OSGi developers by ensuring that each Restlet module distributed as a JAR file was also a valid OSGi bundle, including correct manifest information.
We also ensured that dependent libraries were distributed as bundles as part of the various Restlet editions and distributions (Zip and Windows installer).
In practice, OSGi development isn’t supported on platforms such as Android, GAE and GWT, leaving the developer free to choose from either the Java SE or Java EE editions of Restlet, as both contain different extensions usable in OSGi such as the Servlet and Jetty extensions.
Progressively, we realized that a new edition of Restlet dedicated to OSGi environments such as Equinox and Felix was necessary to clarify the situation and make space for more OSGi specific features.
Eclipse Update Site
In addition, we worked hard on providing a new distribution channel specific to this OSGi edition : an Eclipse Update Site supporting easy installation and automated update right from Eclipse.
Note that this is only recommended if you intended to develop OSGi applications leveraging Restlet, not applications for other target environments such as Java EE or GAE. In the later cases, you should either manually copy the JAR files in your Eclipse project or rely on our Maven repository using a tool such as m2eclipse.
In order to use the Eclipse update site, you should simply use this URL: http://p2.restlet.org/2.1/
More detailed instructions about using this update site are available on this page.
Restlet integration with ECF
This integration supports the OSGi Remote Services specification by adding REST/HTTP bindings based on Restlet and leveraging the Restlet extension for OSGi introduced below.
Upcoming Restlet extension
Finally, based on work initiated via a Google Summer of Code project in 2010, a Restlet extension for OSGi is entering in the Restlet Incubator with the goal to become part of the 2.2 version of the framework.
The extension facilitates the development of very dynamic Restlet applications, supporting for example the live addition of resources and virtual hosts.
Step after step, Restlet support for OSGi and the Eclipse ecosystem is growing and we will continue to work in this direction, with plans to add visual tooling for Restlet in Eclipse and to provide more integration with OSGi standard services such as the log service. As always, stay tuned!
Restlet Framework 2.1 RC1 and 2.0.10 released October 7, 2011Posted by Jerome Louvel in GAE, RDF, Restlet Releases, Security.
add a comment
Here is the first Release Candidate of 2.1 which freezes the features scope and the public Restlet API. It also marks the beginning of a stabilization and optimization phase.
In order to reach 2.1.0 early next year, we want to fix as many issues reported in our tracked as possible and welcome any help on this front, especially reproducible test cases and patches.
We will also complete the Restlet in Action book, which has already 10 chapters out of 11 written and most appendices ready as well. Manning should be sending a MEAP update emails very soon now, taking into account great feed-back from readers and technical reviewers.
In the coming weeks, we will also start working on version 2.2, but we will come back on this exciting topic in another blog post !
First, the 2.0.10 version fixes 11 issues on the stable branch including:
- HTTP DIGEST signature issues when targeting several URIs
- Web form empty issue on the GAE edition
- RDF writing issue with XML and n3 formats
In addition, version 2.1 RC 1 contains several major enhancements and new features summarized below.
- Added ChallengeScheme.HTTP_AWS_QUERY constant to Crypto extension with client-side support for Amazon Web Services special authentication scheme (using URI query parameters)
- Better handling of special URI characters when encoding and decoding to workaround JDK’s URLEncoder/Decoder limitations
- Added syntactic sugar to the RDF extension
- Added ClientResource#addQueryParameter and addSegment methods
- Added ClientInfo#certificates and cipherSuite properties
- Added Authenticator#multiAuthenticating to better control optional authenticators and prevent several authentications if not necessary.
- Updated all Apache libraries to recent versions
- Updated Jackson to version 1.9.0
- Updated FreeMarker to version 2.3.18 (security fix!)
- Alex Milowski
- Arjohn Kampman
- Avi FlaxBjorn Roche
- Bryan Hunt
- Cyril Lakech
- George Calm
- Henry Story
- Matt Stromske
- Raif S. Naffah
- Sebastien Schneider
- Steve Ferris
- Warren Janssens
Thanks to all others who helped us in various ways for this milestone.
Can the rise of SPDY threaten HTTP? October 6, 2011Posted by Jerome Louvel in General, REST, Restlet, Restlet General.
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?