The first implementable draft of HTTP/2.0 was released on July 8th by the HTTPbis working group of the IETF. The 2.0 version of HTTP is based on the SPDY protocol developed by Google — in fact, the initial draft was a copy of the SPDY specification as a base for diffs.
Photo by Jeffrey Beall
HTTP/2.0 is intended as an alternative to HTTP/1.1, rather than deprecating the old version. There is good reason for this: The new version feels similar to the old, but there are important differences designed to enable more efficient network communication.
It’s important to note this is still a draft. There will undoubtably be numerous changes between now and the scheduled submission in November 2014 to the IESG for consideration as a proposed standard. It’s also worth noting again that 1.1 and 2.0 will be expected to operate simultaneously, using agent negotiation between clients and servers to determine which to use. There will be no impending deadline to trip up developers who are behind: HTTP 1.1 will continue to be a standard for the foreseeable future. Front-end web development will undergo drastic changes as sites begin to take advantage of the new features in 2.0.
HTTP APIs will be less affected assuming quality libraries appear. Once 2.0 is as easy to implement as 1.1, we will be able to utilize new features to more efficiently use bandwidth and persistent connections. While the concept of 2.0 becoming a binary (as opposed to ASCII) protocol is controversial to many, hopefully most of that will be abstracted away. So don’t bring your torches and pitchforks out until we go through some of what you’ll be getting!
Streams & Multiplexing
One of the most interesting changes for both developers of web front-ends and REST APIs is the expected case that connections will remain open so long as they stay on that page or site. While this is possible with persistent connections in 1.1, the new version adds support for multiple frame streams over the same underlying TCP connection. These streams will be able to be prioritized and transmission order will only matter within the context of a stream, not between streams.
This will allow servers to send the most important data first, while waiting to send less important data. Rather than opening multiple connections for every necessary resource if we want to load them at the same time, we will now be able to open multiple streams over the same connection with less HTTP overhead.
Server Resource Pushing
Another new concept is the ability for the server to push additional data over an established connection. While the concept itself is hardly revolutionary — this is after all how TCP itself functions – bringing this capability to the widespread HTTP world will be no small improvement and may help marry the simplicity of an HTTP API with the fully-duplexed world of TCP.
This capability is mostly designed for web pages. Efficient sites typically minimize number of requests required to render the entire page by minifying resources such as images and scripts. With a push, the server will be able to proactively tell the client about additional resources required to render the page.
This may also be useful for APIs, too. For example, API responses may be able to be batched easier. Some existing APIs have batch calls, allowing multiple API calls to be done in one request. It may be possible to cleverly use server pushes to respond to these, rather than packing the responses into one object.
Will you want to follow this?
Anyone developing HTTP APIs who wants to stay on the forefront of technology will want to at least read the 2.0 specifications. With this knowledge you can determine how you may take advantage of it for new APIs, or APIs that may be in need of a re-engineering already. This won’t be a highly disruptive technology that everyone will switch to immediately. After all, as of today it won’t be submitted to the IESG for over a year.
However, SPDY was only announced 3 years ago and already has tentative support by Chrome, Firefox, and Opera. Google, Twitter, and Facebook already support SPDY. With HTTP/2.0 as more or less the open version of the standard (Google has a trademark on SPDY), it won’t likely be far behind.
