Skip to content

Instantly share code, notes, and snippets.

@pesterhazy
Created November 2, 2023 12:58
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save pesterhazy/3c6c98aa96b5a848608cd79604be3cf0 to your computer and use it in GitHub Desktop.
Save pesterhazy/3c6c98aa96b5a848608cd79604be3cf0 to your computer and use it in GitHub Desktop.
HTTP endpoints and handling third party service failures

Let's say I'm building a backend endpoint /find-icon?q=apple as part of a large monolithic app. What it does is simply forward the request to a 3rd party service, FindIcon.com. Essentially it's a proxy except that it adds FindIcon.com API credentials.

What should this endpoint do in the case of an 400–599 status response from the 3rd party service? Specifically:

First, what status code should /find-icon return in case of a third-party error? Each class of codes seems to have downsides:

  • 20x hides the error from the client. For example, it doesn't show up in red in the browser tab, making debugging harder.
  • 40x seems semantically wrong, given that, according to the HTTP spec, "the 4xx (Client Error) class of status code indicates that the client seems to have erred".
  • 50x on the backend or Load Balancer typically causes backend alerts, which are set to trigger when X amount of 50x errors occur in a given time frame. This will cause an on-call incident, waking up people, which may or may not be what you want, depending on the business importance of the service.

Second, what concrete steps, other than relying on HTTP status codes, can you take to make sure third-party failures can be monitored?

I'm looking for industry best practices and advice. Everyone makes HTTP request to 3rd parties, so this is a very common problem – what do companies typically do?

@pistazie
Copy link

pistazie commented Nov 2, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment