The request response model of HTTP communication usually involves synchronous communication. A client requests a resource at a server and blocks until the response has been transmitted. Asynchronous communication using HTTP is therefore typically archived on a conceptual basis. The synchronous HTTP invocations can trigger long-running business processes. The external system can then either notify the caller by another mechanism later on or offer functionality for polling for updates.

For example, a sophisticated user management system offers methods to create users. Assume users need to be registered and legitimized in external systems as part of a longer-running, asynchronous business process. The application would then offer an HTTP functionality, such as POST /users/, which starts the process to create new users. However, invoking that use case does not guarantee that the user will be created and registered successfully. The response of that HTTP endpoint would only acknowledge the attempt to create a new user; for example, by the 202 Accepted status code. This indicates that the request has been accepted, but has not necessarily been processed completely. The Location header field could be used to direct to the resource where the client can poll for updates on the partly-finished user.

On a technical level, HTTP does not only support synchronous invocations. In Sub-chapter Server-sent events, we will have a look at server-sent events as an example of a HTTP standard using asynchronous message-oriented communication.