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.
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.
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:
Asynchronous APIs are essential for bidirectional streaming. When you have a bidirectional connection, the client and server can continuously send messages to one another. HTTP/2 supports this type of connection by default. While it is technically possible to stream data over HTTP (usually known as chunking), it adds complexity on the client side and you can be slowed down by buffer limits and other issues. You will have a much better experience when you use HTTP/2 to stream data.
Example asynchronous API use cases
These are a few examples of applications that might use an asynchronous API:
- Messaging
- Social media
- Mobile games
- Banking
Better together
In many cases, applications benefit from using a combination of synchronous and asynchronous APIs. While asynchronous APIs can offer perks like faster communication, quicker response times, and reliable scaling, there are advantages to synchronous APIs. For example, if you need to make sure that requests are processed in a specific order, synchronous API calls are a better fit. Synchronous APIs are also less complex to set up, so they’re still ideal for a straightforward request-response pattern. If you’re not already using asynchronous APIs, you can start to incorporate them while keeping the functionality of your existing REST APIs.
Learn more about asynchronous APIs
Ready to dig into more asynchronous APIs in Postman? Check out these resources:
- Postman Level Up: Test gRPC APIs
- How We Built It: gRPC Support
- Postman Labs documentation for gRPC support
- Postman Labs documentation for WebSocket support
Technical review by Arlemi Turpault and Gbadebo Bello.
Oldest comments (0)