The majority of APIs today are based on the Hypertext Transfer Protocol (HTTP). HTTP has been around for a very long time, in computer terms. It is the protocol underlying the Web and has changed surprisingly little since its inception in 1989. HTTP/1.1 was first standardized in 1997 and since then has been updated, but it was never replaced.
HTTP/2 was released in 2015, but did not change the way how HTTP works for HTTP users. The update made the protocol more efficient by changing the way in which HTTP servers and clients communicate. However, HTTP/2 still had some shortcomings which were largely caused by the protocol using the Transmission Control Protocol (TCP) as its foundation.
HTTP/3 is not yet published as a standard, but it is finished as a protocol and is currently in the last stages of the publication process. HTTP/3 is an even more radical re-thinking of HTTP than HTTP/2 was. It replaces the TCP protocol (which is the transport protocol underlying most Internet protocols) and uses the User Datagram Protocol (UDP) as a foundation instead.
On top of this, it places a new connection-oriented transport protocol called QUIC. With this approach, shortcomings of HTTP/2 could be addressed, and as a result, HTTP/3 provides substantial improvements over HTTP/2 and of course HTTP/1.1.
Robin Marx of KU Leuven (@programmingart on Twitter) explains how HTTP/3 changes things from the perspective of API designers and consumers. There are two main areas where HTTP/3 changes the way how HTTP APIs are behaving:
- Head-of-line-blocking. HTTP/2 improved the pipelining of requests in HTTP/1.1 by multiplexing parallel transfers over one connection. However, because the underlying TCP still treats these parallel streams as one logical connection, one missing packet can block all multiplexed streams. HTTP/3 changes this because QUIC is aware of the fact that there are parallel transfers going on, meaning that one missing packet does not block all streams. This means that HTTP APIs can more confidently rely on multiple resource transfers being efficiently managed by the underlying protocol stack.
- Slow handshake. Because of the separation of protocols in pre-HTTP/3 protocols, initiating a connection and getting the first response takes several round trips. For APIs that are used in applications that directly affect User Experience (UX), this delay can mean that an application’s reaction can be perceived as slow. HTTP/3 adds Zero-Round-Trip-Time (0-RTT) which allows an API to send a response as part of initially establishing the connection. This means that responses can be sent quicker and therefore an application’s reaction to a user request can be quicker than with previous versions of HTTP.
If you’re interested in more details and explanations, check out this video in which Robin Marx explains the issues, how they affect HTTP API, and how HTTP/3 addresses those issues.
Learn how to bring your APIs in from the wild.