What to consider when discussing HTTP/2

[madhans]

HTTP/2 introduced in May 2015 via RFC 7540 is an improvement to HTTP protocol and comes with a few nifty improvements to the underlying protocol that powers the web.

Several new features in the HTTP, Web and HTML worlds have come to bear on APIs and like any discerning practitioner one needs to identify the problem a new feature addresses and prioritize what they want to incorporate in their systems.

HTTP/2 is set of enhancements that primarily provide performance improvements to the HTTP protocol. The 3 introductions made are header compression, concurrent exchange and server push. The new features are distinctly different to and do not replace streaming, web sockets or notifications that are often discussed in app development.

Header compression

HTTP headers have come to carry significant number of bytes as designers tend to use it for metadata that cannot be part of the payload. Typical examples are correlation id, version information, client information etc., The cookie header is particularly a big one. HTTP/2 offers compression of headers to reduce the bytes on the wire.

In the API world cookies are irrelevant. When an API seems to have multiple custom headers it could be the result of old habits from integration era. Remember HTTP headers carry optional metadata information. If you see a header mandated in an API it is worth remodeling the API to include it in the payload. A good reference is "JSON API" specification that provides placeholders for meatdata and related information in the payload.

If HTTP/2 is justified because it specifically offers header compression, it is worth revisiting if there is an API design problem to address.

Concurrent Exchanges

Browsers tend to load multiple resources like CSS, js scripts and images to render a page. They also make API calls. Most modern browsers can use HTTP/2 to perform concurrent exchanges on a single connection to a server and not be blocked on a single time consuming resource.

While a web page tends to load several resources like CSS, scripts, fonts, images etc., it is worthwhile to take the outside-in perspective to see how many API calls are needed to render specific pages in web and mobile applications. What is the traffic the web page itself would see and how many API calls seem to be the norm.

Concurrent exchanges do reduce the number of network connections to the server and reduce the load on the server. However, given the usecase and app context it is worth evaluating the improvement in performance with concurrent exchanges w.r.t APIs.

Remember web resource like CSS, js scripts and images can use HTTP/2 irrespective of how APIs are invoked. Most modern browsers provide support for HTTP/2, but remember some code change may be required in the client to reap the benefits and setting out to estimate the changes will help in assessing the performance benefit after the change.

Server Push

Server Push proactively sends resources to a client in the anticipation that the request for the resource is highly expected from the same client shortly. A common scenario is to line up CSS, js scripts, images etc., even before the browser asks for them. This needs to be used with Server Sent Events (SSE) to provide bidirectional communication. Server Push by itself does not replace Websockets, a different mechanism to achieve bidirectional communication.

It is easy to confuse Server Push with asynchronous pattern in APIs that involve a callback URL, these are two different scenarios. An asynchronous API allows the server to invoke an endpoint in the client application when a job completes. Asynchronous APIs require many other considerations like callback registration and callback security and is a very different usecase.

Closing Notes

As of writing this article Apigee does not support HTTP/2 and there is every reason it will be eventually supported. In the meantime, when discussing HTTP/2 support it is important to understand the HTTP/2 benefits that matter to you and ensuring diligence in the process.