Best practices for your developers to follow

The Plum Guide does not guarantee 100% uptime on its API endpoints, due to this building in resiliency to failure is vital to ensure there is no loss of data for the user.

Check for successful status codes

In each of the requests being sent to Plum Guide API will return back a success response if we have processed the request successfully. Our Responses vary depending on the very you are using (POST, DELETE etc).

  • Successful GET request - 200 Ok
  • Successful POST request - 201 Created
  • Successful DELETE request - 204 No Content

For a full list of success codes see the list here

Check for failed status codes

In each of the requests being sent to the Plum Guide API will get a failed response if something has gone wrong. Failure can happen due to a multitude of reasons. Below are some of the common response code to look out for.

  • Request is unauthenticated
    1. 401 Unauthorised
    2. 403 Forbidden
  • URL request is 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 for you to 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 in 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 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