It is always interesting to note how even today's Cloud giants continue to draw a largely imaginary line between Synchronous and Asynchronous HTTP Requests, such as in the case of a typical REST API call. This line, we are asked to believe, very clearly separates Synchronous Requests – where the Request is made and the caller holds the line until receiving a Response from the relevant HTTP API Endpoint – from Asynchronous Requests – where the caller fires off their Request, (typically) gets a 202 Status Code in reply, and then waits for the actual API Response via some other channel; such as a Webhook, WebSocket, or using the 'HTTP Polling' Pattern described by Microsoft in its Asynchronous Request-Reply pattern Article.
We read in this same Article that: "Most APIs can respond quickly enough for responses to arrive back over the same connection… In some scenarios, however, the work done by [the] backend may be long-running, … [and] it isn't feasible to wait for the work to complete before responding to the Request. This situation is a potential problem for any synchronous request-reply pattern… Some architectures solve this problem using a message broker to separate the request and response stages… But this separation also brings additional complexity when the client requires success notification, as this step needs to become asynchronous."