Understanding asynchronous APIs

Melinda Gutermuth

August 26, 2022

If you’ve worked mostly with REST APIs, you might not be as familiar with asynchronous API protocols like WebSocket and gRPC. Asynchronous APIs allow you to stream data, send multiple requests at the same time, and manage communication intelligently between services, while synchronous APIs require you to make a new request every time you need data. You can do a lot of the same things with both types of APIs, but you’ll find that some use cases are a better fit for one or the other. Let’s take a closer look at what makes asynchronous APIs different from synchronous APIs.

Related: The different types of APIs

The difference between asynchronous and synchronous APIs

Synchronous APIs often use HTTP or HTTPS for transport, and HTTP is a unidirectional protocol. The client sends a request to the server, and then the server sends an HTTP or HTTPS response back. Asynchronous APIs tend to use bidirectional protocols like HTTP/2. When you use a bidirectional protocol, the client and server can maintain their connection, sending and receiving data for as long as they need to. You can think of it like this: when you make a synchronous request, you pull data from a server, but you can use an asynchronous request to ask the server to push the latest data to you.

When you send a request to an asynchronous API, your application can continue to process other instructions for your user while it waits for a response from the API server. This is different from a synchronous API, where the application won’t continue until it receives the response. If a resource, service, or datastore is not available immediately when you make the request, an asynchronous API can use a callback such as a webhook to notify your application when the resource is ready.

Related: What is GraphQL?

Not all API architectures fit neatly into the synchronous or asynchronous labels. For example, GraphQL can be considered synchronous because you send queries over HTTP, but it also supports asynchronous messaging using WebSockets with its subscription server. You can register with the GraphQL subscription server to receive asynchronous updates, with the added benefit of choosing exactly which fields you want included in the response. To see an example of a GraphQL API in Postman, check out the New Relic Nerdgraph GraphQL API Collection or our GraphQL examples workspace.

When to use an asynchronous API

Microservices are an excellent use case for asynchronous API requests. When you configure your application’s internal and external services to communicate with one another asynchronously, the services can send each other messages without necessarily being available at the same time, often by using a message broker to handle the requests. Instead of polling for new information, services can subscribe to the events that matter to them and receive push updates. Event-driven architecture relies on this publish-subscribe pattern of communication between services. This diagram shows an example of two event producers that share events with three services using the publish-subscribe pattern:

HTTP/2 also supports an unlimited number of messages over a single connection, so services can exchange data without having to initiate a new connection each time they make a request, as they do with HTTP. This makes them less likely to run up against a browser’s TCP connection limits. It also allows applications to communicate with the API in the background while executing other tasks, which leads to better performance and scaling for an application with a lot of user activity. The gRPC framework is a popular choice for internal services because it allows them to efficiently stream data to one another using structured data payloads.

Check out our recent Postman Level Up video about gRPC in Postman: