Migrating your REST APIs to HTTP/2: Why and How?

Migrating your REST APIs to HTTP/2: Why and How?


Image: https://auth0.com

As developers, our primary aim has always been to deliver faster, more seamless experiences to the users of our products. This continuous desire to better productivity and experiences lead us to upgrade our technologies almost constantly. We migrate to newer versions of our languages, web frameworks, messaging queues and text processors and operating systems. But somehow, the fundamental protocol used universally by web applications, the HTTP protocol missed an upgrade for more than a decade.

HTTP/1.1 is great, but as web applications grow in size and complexity, it’s age is starting to show. This is a great time to make the upgrade to HTTP/2.

What happened to HTTP/1.2?

The goals of the new HTTP were set very high, and in order to achieve those metrics, there was a fundamental change in how data is traversed across the network. HTTP/2 introduces a new binary framing layer that breaks backward compatibility with HTTP/1.x clients and servers. Hence, the versioning jump to 2.0.

What is this new binary framing layer?

It is a simple design choice. HTTP/1.x traditionally used newline-delimited text to transfer data. It is slower, larger, and more error-prone compared to binary.

Source: developers.google.com

This layer, thus, refers to a change in the design of how the data is encoded between the sockets and the HTTP APIs we expose from our applications, and not the APIs themselves. The web container that will run the application will take care of doing this encoding based on the HTTP version it supports, which no changes need to be made to the API layer.

The semantics are still the same. You can still use traditional GET, PUT, POST, DELETE just as you did in HTTP 1.x.

What are my key benefits?

Without going into great detail of how binary streams work, let us sum it up with this one statement and move on to how it can help us:

HTTP/2 breaks down the HTTP protocol communication into an exchange of binary-encoded frames, which are then mapped to messages that belong to a particular stream, all of which are multiplexed within a single TCP connection.

Now, on to the benefits:

1.Binary Processing: Binary content is faster, lighter, and more compact. Instead of having four different message parsing options in HTTP/1.x, HTTP/2 has just one. Also, binary content affords more support for processing capitalizations, whitespaces, blank lines and few other notions difficult to portray in text.

2. Multiplexing: HTTP/1.x was fundamentally built over the principle that only one response can be delivered at a time. This led to response queueing and blocking, slowing down the TCP connection. This meant till now, the client had to guess the right order of responses it needs to fetch to be able to process things quickly.

Source: SessionStack

HTTP/2 does away with this concept, and the new binary streams make possible full request and response multiplexing. Thus, the client just needs one connection per origin to be able to deliver multiple requests and responses in parallel, without any of them blocking each other. This, in turn, delivers lower page load times by eliminating unnecessary latency and improving the utilization of available network capacity.

3. Header Compression: HTTP/2 uses the HPACK compression technique to compress header data across requests and responses.

Source: GlobalDots

HPACK compresses the headers using Huffman encoding, while the client and server maintain a list of previously seen headers for quicker encoding and interpretation. 
In today’s average requests, we can see headers crossing several kilobytes with cookies, and header compression greatly improves efficiency.

4. Server Push: In HTTP/1.x, a server can communicate to the client only when a request is made to it, and it can communicate only by responding to that particular request. In HTTP/2 however, a server can send multiple responses to a single request. Thus, in addition to responding, the server can push other useful information to the client. 
For example, while loading a webpage, the server can start sending the javascript files and stylesheets right away, without waiting for the client to ask for them. It may also be used to activity update the client’s cache for faster rendering.

How do I move to HTTP/2?

As a result of the so many benefits, organizations have been steadily moving towards HTTP/2, it’s usage ever increasing. As of now, 32.4% of all websites use HTTP/2. The industry is confident this number can only go upwards. So how do you jump on this train?

As mentioned before, no real changes need to be made to the application layer to transition to HTTP/2, as the changes are in the encoding and information transfer mechanisms.

If you are using cURL , just check the current version with

curl --version

You will be responded with a list of protocols : dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp . If you do not see http2 included there, you can simply update your cURL version.

Mac users can simply do

brew reinstall curl --with-openssl --with-nghttp2

For other operating systems, you can follow this helpful article.

Now how about updating your web servers and containers? Each one has a slightly different but very simple and minimal change required to make the upgrade, with no issues in compatibility with existing code.

I primarily used Spring Boot for my applications. It has an embedded tomcat server, which has been supporting HTTP/2 since version 1.4.x , which has Tomcat version 8.5.x . All we need to do is add the HTTP 2 upgrade protocol to Tomcat’s connector. We can do that by customizing the embedded Tomcat container:

public EmbeddedServletContainerCustomizer tomcatCustomizer() {
    return (container) -> {
        if (container instanceof TomcatEmbeddedServletContainerFactory) {
            ((TomcatEmbeddedServletContainerFactory) container)
                    .addConnectorCustomizers((connector) -> {
                connector.addUpgradeProtocol(new Http2Protocol());

It’s that simple!

All popular web frameworks now support HTTP/2, and the migration is quite simple and provides us with a ton of benefits in delivering better experiences to our users. I hope this article nudged you in the direction of HTTP/2 migration.

I hope you enjoyed this lesson. Should you have any questions, feel free to comment below or email me at arindamroynitw@gmail.com.

If you like what you read, clap for the article below and follow me for more content.