Asynchronous  Request-Reply

Decouple backend processing from the front-end host, where backend processing needs to be asynchronous, but the frontend still needs a clear response. 

When to use this pattern?  

• Client-Side code (browser), where it’s difficult to provide call-back endpoints, or the use of longrunning connections adds an additional complexity  

• Service calls where only the HTTP protocol is available and the return service can’t fire callbacks because of firewall restrictions on the client side.  

• Service calls that need to be integrated with legacy architectures that don’t support modern callback technologies such as WebSockets, or Webhooks. 

When NOT to use this pattern?  

• You can use a service built for asynchronous notifications instead (Azure Event Grid).

• Responses must stream in real time to the client.

• The client needs to collect many results, and received latency of those results is important.  

• You can use server-side persistent network connections, such as WebSockets.  

• The network design allows you to open up ports to receive asynchronous callbacks or webhooks.

In this pattern, the Azure function apps can be replaced with app services, queue by service bus and blob storage by any other cloud-based storage based on the requirements.

Considerations  

• There are a number of different ways to implement this pattern over HTTP. Make sure the response code is passed.

• HTTP 202 response should indicate the location and frequency that the client should poll for the response.  

-Location  

-Retry-After  

• You may need to use a processing proxy, or façade.  

• If the status endpoint redirects on completion, HTTP 302 or HTTP 303.  

• Upon successful processing, you should return the right response code: HTTP 200 (OK), HTTP 201 (Created), HTTP 204 (No Content). 

• If an error occurs during processing, persist the error at the resource URL described in the location header, and return the appropriate response code HTTP (4xx).

• Not all solutions will implement this pattern the same way, and some services will include additional headers.  

• Some legacy clients might not support this pattern.

• Allow clients to cancel long-running requests.