The default model for client-server communication is request-response. The client sends a request, the server returns a response, and the connection closes. This handles the majority of what most software needs to do, and it covers an enormous range of practical scenarios in modern web applications.

It doesn’t handle everything. Some work takes too long to complete inside a single request. Some events happen on the server’s schedule, not the client’s. Some interactions are continuous rather than one-shot. And some messages need to outlive the moment they were sent.

Async API patterns are the techniques engineers use for these cases, and the list has grown over the years. It now includes short polling, long polling, server-sent events, WebSockets, webhooks, async APIs with status polling, message queues, and GraphQL subscriptions. Each has its own design and preferred use case. What they share is one purpose, which is to extend what’s possible beyond a single HTTP request and response.

In this article, we will look at each of these patterns in detail, along with their advantages. We’ll start by looking at where request-response stops fitting and then walk through each pattern in turn.