Client Side Resilience

There could be instances where we cannot process requests, due to unforeseen circumstances, related to technical limitations. Building resiliency to failure is vital to ensure there is no loss of data between the client and our servers.

Check for successful status codes

Each of the requests being sent to Plum Guide API will return back a response with a status code. Each status code will indicate whether the operations have been completed. The various successful responses can be:

• Successful GET request - 200 Ok
• Successful POST request - 201 Created
• Accepted POST request - 202 Accepted (used for Asynchronous endpoints)
• Successful DELETE request - 204 No Content

For a full list of success, codes see the list here

Check for failed status codes

Failure can happen due to a multitude of reasons, below are some of the common response codes to look out for.

• Request is unauthenticated
  1. 401 Unauthorised
  2. 403 Forbidden
• URL request being sent to is not found
  1. 404 Not Found
• Request being sent is not in the correct shape
  1. 400 Bad Request
• Request VERB is incorrect
  1. 405 Method Not Allowed
• Plum Guide API is failing
  1. 500 Internal Server Error
  2. 504 Gateway Timeout

For a full list of failure, codes see the list here. For failures resulting in a 500+ code, it's recommended that you add a retry policy (see next section). For all other status codes please check the request you are sending.

Adding retry policies

A recommended approach is to add retry policies to all HTTP requests being sent. Retry policies allow requests to be replayed within a specified timeframe. A very basic example is a retry policy that replays on a static timeframe, 10 seconds in the example below up to 5 attempts.

• Attempt 1
• Attempt 2 - 10 Seconds after
• Attempt 3 - 20 Seconds after
• Attempt 4 - 30 Seconds after
• Attempt 5 - 40 Seconds after

Plum Guide recommends using an exponential backoff policy. In this method, each retry attempt increases in size exponentially to allow a longer period of time before trying again. Below is an example of what an exponential backoff policy looks like with a 10-second interval of up to 5 attempts.

• Attempt 1
• Attempt 2 - 10 Seconds after
• Attempt 3 - 20 Seconds after
• Attempt 4 - 40 Seconds after
• Attempt 5 - 80 Seconds after