Benefits of REST APIs With HTTP/2

DZone 's Guide to

Benefits of REST APIs With HTTP/2

HTTP/2 brings with it a lot of benefits for REST APIs, both on the integration side of things and in terms of performance and security.

· Integration Zone ·
Free Resource

HTTP/1.x vs HTTP/2

First, let's look at some of the high-level differences:

HTTP/2 Is Binary, Instead of Textual

Binary protocols are more efficient to parse, more compact "on the wire," and, most importantly, they are much less error-prone compared to textual protocols like HTTP/1.x, because they often have a number of affordances to "help" with things like whitespace handling, capitalization, line endings, blank lines, and so on.

For example, HTTP/1.1 defines four different ways to parse a message; in HTTP/2, there's just one code path.

HTTP/2 Is Fully Multiplexed, Instead of Ordered and Blocking

HTTP/1.x has a problem called "head-of-line blocking," where effectively only one request can be outstanding on a connection at a time.

HTTP/1.1 tried to fix this with pipelining, but it didn't completely address the problem (a large or slow response can still block others behind it). Additionally, pipelining has been found very difficult to deploy, because many intermediaries and servers don't process it correctly.

This forces clients to use a number of heuristics (often guessing) to determine what requests to put on which connection to the origin and when; since it's common for a page to load 10 times (or more) the number of available connections, this can severely impact performance, often resulting in a "waterfall" of blocked requests.

Multiplexing addresses these problems by allowing multiple request and response messages to be in flight at the same time; it's even possible to intermingle parts of one message with another on the wire.


HTTP/2 Can Use One Connection for Parallelism


One application opening so many connections simultaneously breaks a lot of the assumptions that TCP was built upon; since each connection will start a flood of data in the response, there's a real risk that buffers in the intervening network will overflow, causing a congestion event and retransmits.

You can see a demo of how HTTP/2 is working here: https://http2.akamai.com/demo

Additionally, using so many connections unfairly monopolizes network resources, "stealing" them from other, better-behaved applications (e.g., VoIP).

HTTP/2 Uses Header Compression to Reduce Overhead

If you assume that a page has about 80 assets (which is conservative in today's Web), and each request has 1400 bytes of headers (again, not uncommon, thanks to Cookies, Referer, etc.), it takes at least 7-8 round trips to get the headers out "on the wire." That's not counting response time - that's just to get them out of the client.

This is because of TCP's Slow Start mechanism, which paces packets out on new connections based on how many packets have been acknowledged - effectively limiting the number of packets that can be sent for the first few round trips.

In comparison, even a mild compression on headers allows those requests to get onto the wire within one roundtrip - perhaps even one packet.


HTTP/2 Allows Servers to "Push" Responses Proactively Into Client Caches


Server Push potentially allows the server to avoid this round trip of delay by "pushing" the responses it thinks the client will need into its cache.

However, pushing responses is not "magical" - if used incorrectly, it can harm performance. For now, many are still will continue to work with Webhooks.

How Does This Affect the Existing REST APIs Built on HTTP/1.1?

The main semantic of HTTP has been retained in HTTP/2. This means that it still has HTTP methods such as GET, POST, HTTP headers, and URIs to identify resources.

What has changed in HTTP/2 with respect to HTTP/1.1 is the way the HTTP semantic (e.g. "I want to PUT resource /foo on host domain.com") is transported over the wire. This means that REST APIs built on HTTP/1.1 will continue to work transparently as before, with no changes to be made to applications.

The web container that runs the applications will take care of translating the new wire format into the usual HTTP semantic on behalf of the applications, and the application just sees the higher level HTTP semantic, no matter if it was transported via HTTP/1.1 or HTTP/2 over the wire.


The other major improvement present in HTTP/2, HTTP/2 Push, targets the efficient downloading of correlated resources, and, as it's probably not useful in most REST API use cases, perhaps only the Object Storage like services can benefit from this (like Amazon S3).


Thanks to Simone Bordet for his answer on StackOverflow (https://stackoverflow.com/questions/31692868/rest-api-with-http-2/)

HTTP/2 Benefits Explained



Bidirectional Communication Using Push Requests

HTTP/2's "server push" allows a server to proactively send things to the client's cache for future use.


It's also useful for proactively updating or invalidating the client's cache, something that people have asked for.

Of course, in some situations, the client doesn't want something pushed to it - usually because it already has a copy, or knows it won't use it. In these cases, it can just say "no" with RST_STREAM.

Multiplexing Within a Single TCP Connection


Furthermore, it adds header compression, so that the normal request and response headers don't dominate your bandwidth - even if what you're requesting is very small. That's a huge win on mobile, where getting big request headers can easily blow out the load time of a page with a lot of resources by several round trips.

Long Running Connections

HTTP/2 is designed to use fewer connections so servers and networks will enjoy less load. This is especially important when the network is getting congested because HTTP/1's use of multiple connections for parallelism adds to the problem.

For example, if your phone opens up six TCP connections to each server to download a page's resources (remembering that most pages use multiple servers these days), it can very easily overload the mobile network's buffers, causing them to drop packets, triggering retransmits, and making the problem even worse.


Stateful Connections

If your HTTP/1 client sends a request and then finds out it doesn't need the response, it needs to close the connection if it wants to save bandwidth; there's no safe way to recover it.





Using Binary Instead of Text

This is also a good and a not so good feature.

One of the nice things about HTTP/1 is the ability to open up telnet, type in a request (if the server doesn't time out!) and then look at the response. This won't be practical in HTTP/2 because it's a binary protocol. Why?







Of course, all of this is small solace for the poor ops person who just wants to debug the protocol. That means that we'll need new tools and plenty of them to address this shortcoming; to start, Wireshark already has a plug-in.

More Encryption

HTTP/2 doesn't require you to use TLS (the standard form of SSL, the Web's encryption layer), but its higher performance makes using encryption easier since it reduces the impact on how fast your site seems. This means that you will probably need to buy SSL certificates, renew them, etc. This is not a small amount money to spend when you are working with many microservices using REST APIs.

In fact, many people believe that the only safe way to deploy the new protocol on the "open" Internet is to use encryption; Firefox and Chrome have said that they'll only support HTTP/2 using TLS.

They have two reasons for this. One is that deploying a new version of HTTP across the Internet is hard, because a lot of "middleboxes," like proxies and firewalls, assume that HTTP/1 won't ever change, and they can introduce interoperability and even security problems if they try to interpret an HTTP/2 connection.

The other is that the Web is an increasingly dangerous place, and using more encryption is one way to mitigate a number of threats. By using HTTP/2 as a carrot for sites to use TLS, they're hoping that the overall security of the web will improve.



HTTP/2 does not define a JavaScript API nor does it help you build your REST APIs much more easily. For now, JavaScript clients running in a web browser can make only limited use of the new capabilities. However, for server-to-server communication, HTTP/2 provides a lot of ways to go beyond existing REST APIs.

Furthermore, the downside of HTTP/2's network friendliness is that it makes TCP congestion control more noticeable; now that browsers only use one connection per host, the initial window and packet losses are a lot more apparent.

Just as HTTP has undergone a period of scrutiny, experimentation, and evolution, it's becoming apparent that the community's attention is turning to TCP and its impact upon performance; there's already been early discussion about tweaking and even replacing TCP in the IETF.

api development ,http 2 ,integration ,rest apis


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}