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?