Asynchronous

Request-Reply Pattern
What is Asynchronous Request-Reply Pattern?
What is Asynchronous Request-Reply Pattern?
 Category
 Messaging
What is Asynchronous Request-Reply Pattern?
 Category
 Messaging

 Decouple backend processing from the front-end host, where backend processing needs to be
asynchronous, but the frontend still needs a clear response.
API
API
API
API
API
API
API
API
API
API
API
API
Considerations
Considerations
 There are a number of different ways to implement this pattern over HTTP
Considerations
 There are a number of different ways to implement this pattern over HTTP
 HTTP 202 response should indicate the location and frequency that the client should poll for the
response.
Considerations
 There are a number of different ways to implement this pattern over HTTP
 HTTP 202 response should indicate the location and frequency that the client should poll for the
response.
 Location
 Retry-After
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 processing proxy, or façade.
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 processing proxy, or façade.
 If the status endpoint redirects on completion, HTTP 302 or HTTP 303
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 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)
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 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)
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 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
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 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
Considerations
 There are a number of different ways to implement this pattern over HTTP
 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 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
When to use this pattern?
When to use this pattern?

 Client-Side code (browser), where it’s difficult to provide call-back endpoints, or the use of
long-running connections adds an additional complexity
When to use this pattern?

 Client-Side code (browser), where it’s difficult to provide call-back endpoints, or the use of long-
running 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.
When to use this pattern?

 Client-Side code (browser), where it’s difficult to provide call-back endpoints, or the use of long-
running 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?
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 needsd 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
When NOT to use this pattern?
When NOT to use this pattern?

 You can use a service built for asynchronous notifications instead (Azure Event Grid)
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

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

 Responses must stream in real time to the client

 The client needsd to collect many results, and received latency of those results is important.
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 needsd to collect many results, and received latency of those results is important.

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

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

 Responses must stream in real time to the client

 The client needsd 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
Thank You!