Slowly but surely, HTTP/2 is becoming the favored protocol for transporting data files between clients and servers. While HTTP/1 used to be the only way of loading web applications, it’s now lagging behind, especially on the UX front.
Since 2015, HTTP/2 APIs have taken the lead with lightning-fast server responses. In particular, they’re responsible for state changes and server responses without the need for browser reloads.
This guide covers some high-level considerations for testing HTTP/2 APIs, as well as some of the best testing tools available today.
What Is HTTP/2?
But first, some history. The internet used to be accessed through a series of request-and-response sessions. These required the browser to load each time a request was sent to the server in order to render a response through a DOM refresh process. This effectively meant you had to load web pages, as each state had different views for each request-response relay.
HTTP/2 does away with the slow asset relay process, instead firing up web applications that often have all the resources loaded in one fell swoop and actively cached on the client-side for faster access.
To better answer the “what is HTTP/2” question, let’s go over some differences between HTTP/2 and HTTP/1.
1. HTTP/2 is binary, while HTTP/1 is textual.
As a textual protocol, HTTP/1 exposes each transaction to any errors, whitespaces, and—the inevitable—more character templates. Binary protocols, on the other hand, resort to low-level communication between nodes, taking every shortcoming from HTTP/1 out of the transport process.
2. HTTP/1 uses a blocked request-response strategy, while HTTP/2 is fully multiplexed.
The back-and-forth request-response relays that an HTTP/1 connection thrives on will create blocks that essentially trigger browser refreshes. With each refresh taking time to process, there’s a noticeable delay on the client side.
Being multiplexed, HTTP/2 saves you all the reloading. Multiple requests can take place in a single direction concurrently.
3. HTTP/2 uses a single connection throughout use.
HTTP/1 sparks multiple connections to fetch responses from the server, but HTTP/2 achieves everything with fewer connections. A single connection now pushes and pulls requests between the client and server.
In fact, since web applications are distributed through microservice architectures, a lot of the transactions in one request/response trip take place between containerized nodes. Server-to-server communication through always-on connections makes more sense than transient connections, as is the case with HTTP/1.
What to Consider When Testing HTTP/2 APIs
You might be tempted to think of HTTP/2 as a completely fresh implementation of the way that browsers feed off servers. However, it’s actually just a set of incremental improvements on normal (older) HTTP/1 ways.
Let’s go over a few things to consider when testing HTTP/2 APIs.
Make Sure You’re Using HTTP/2
Activating HTTP/2 starts on the server-side of your web applications. Then you can create and deploy HTTP/2 APIs accordingly. Most browsers are compatible with HTTP/2 transportation protocols, but you can check which domains are compliant through various browser extensions.
When extensions that check for HTTP/2 are installed, checking compatibility is as simple as observing a blue lightning bolt next to a fully loaded URL.
If either the server or browser you’re bridging with an HTTP/2 API is noncompliant with the newer protocol, connections to your API will be broken automatically. However, HTTP/1 APIs will still transfer files on HTTP/2 compliant channels. Only tests can conclusively tell the difference.
Make Sure Your Tools Support HTTP/2
As you can imagine, there are plenty of tools for testing APIs. The goal is to make sure that your chosen tool supports HTTP/2.
Establish Expected Outcomes
The expected outcomes array differs depending on the kit you apply. Some tools will test the client-side implementations of HTTP/2 APIs, while other tools will strictly confirm compliance with the protocol on either side. There’s no point in using multiple tools, which means you need to map your expected outcomes to the capabilities of any tool you may choose.
Tools to Test HTTP/2 APIs
Now let’s talk about tools you can use to test HTTP/2 APIs. As indicated earlier, some only work on either client or server perspectives.
Speedscale
Speedscale is a comprehensive testing tool for HTTP/2 APIs as you create and deploy them. DevOps teams make rapid changes to applications in production through various deployment methods (blue-green, etc.). Speedscale is an equally rapid API testing tool that fits into CI/CD workflows to seamlessly include the test step and flag any deployment hindrances before they port into production.
The range of tests you can run with Speedscale covers both the client and server sides in both microservice and monochromatic infrastructure models. Speedscale provides an interface to monitor the progress of HTTP/2 API testing, making it easy for teams to retrace any tests for insights at a later stage.
Curl
Curl is an open-source command-line tool (with libraries) you can use to test HTTP/2 APIs. Since it was originally built during the predominantly HTTP/1 era, it now basically uses an ngHTTP/2 implementation and other libraries when testing HTTP/2 APIs.
That said, you should know that the Curl CLI currently doesn’t support tests confirming server push features of the HTTP/2 protocol. This shortcoming means your HTTP/2 applications will have to revert to HTTP/1 methods of requesting data from the server, often without header compression. The lure is that Curl is well established and compatible with a lot of application types and access devices.
H2c
A project in its infancy, H2c is an improvement on the frustrations of Curl—most notably, how Curl doesn’t support the server push feature. To resolve this, H2c (also a command-line-based tool) can hold persistent connections with the server.
In line with the speed-enhancing single and always-listening connection feature of HTTP/2, this allows any server to asynchronously push resources to the client. This, in turn, confirms that your APIs are HTTP/2 compliant.
H2c is a Golang project that can be installed either through builds from its open-source repository to experience the latest features…
go get github.com/fstab/h2c
…or through an operating system-specific implementation.
SmartBear
SmartBear provides an API testing tool that focuses on the performance and virtualization of your APIs as they change with your growing source code files. Part of an entire testing ecosystem of tools, SmartBear plugs into custom workflows to provide test insights as quickly as you make changes to your APIs on both the client and server sides.
HTTP/2 Test Command-Line Tools vs GUI Tools
It should immediately be evident how command-line tools, though lightweight, limit the contemporary methods of testing in production. Notably, they’re heavily dependent on tool-specific commands for navigation and execution of functions within test environments.
Perhaps the most endearing feature of CLI-based tools when testing HTTP/2 APIs is how you can drill down to a specific server or client function and run tests isolated from the rest of the API or HTTP/2 functional points.
Conclusion
By the time you get to this sentence, it should be clear why the internet is migrating toward the HTTP/2 protocol. The technologies and benefits obtained with this protocol make for a more interesting experience from the end-user perspective. From the development angle, being able to create more efficient server resource farmers (APIs) helps reduce the strain of over-optimizing code where the focus should be on module functionality.
The differences between HTTP/1 and HTTP/2 prove a solid usability case, so much so that you should turn your efforts towards creating web applications that comply with the new standards. This often starts with creating and testing your APIs for compliance with the tools discussed.
When it comes to tools, be sure to learn the limits of each option before putting it to use. Some tools are only client-side focused, which could work for static applications. However, with most applications being versioned through continuous integration and deployment, you’ll need a tool that fits perfectly with that agenda.
Even then, most tools on the market are either derivatives of HTTP/1 test methods, as with Curl, and have inherent limitations besides the fact that they’re mostly single feature-focused. Opting for a comprehensive stress-testing tool like Speedscale ensures you cover both the client and server angles of HTTP/2 API testing.
Author Name: Taurai Mutimutema