1

I have a server, which does a request to AWS S3.

What is the correct status code, if my server's request to S3 failed?

Let me break it down more.

  1. "Client" does request to "my server".
  2. "My server" does a request to a "third party server", which fails.
  3. Now "my server" needs to communicate to the "client", that the client's request failed because the request to the third party server failed.

I googled and found that 502 Bad Gateway, might be correct here, but I'm not sure because it also talks about my server being a proxy, which it isn't. My server does additional processing and database calls with the content of the request before the call to AWS S3, as well as after it got the result from AWS.

J. Hesters
  • 13,117
  • 31
  • 133
  • 249
  • This question has [quite a few good answers](https://www.google.com/search?q=rest+500+502+site%3Astackoverflow.com) already, e. g. https://stackoverflow.com/questions/50101598/which-http-status-code-to-use-upon-remote-server-failure-500-or-502 , https://stackoverflow.com/questions/54478905/returning-http-502-error-code-in-restful-api-when-upstream-provider-fails , https://stackoverflow.com/questions/24212794/legitimate-uses-for-http-502 , etc. – ax. Feb 22 '23 at 16:30
  • Does this answer your question? [3rd party API gives back 500 error, what code should my API return](https://stackoverflow.com/questions/25454997/3rd-party-api-gives-back-500-error-what-code-should-my-api-return) – Eggcellentos Aug 09 '23 at 10:22

3 Answers3

3

This is from my experience:

Let's consider your scenario:

  • we have ServiceA and ServiceB
  • the client calls ServiceA
  • then ServiceA calls ServiceB
  • ServiceA returns the result of calling ServiceB to the client

Considering your ServiceA actually does some business logic instead of simply calling ServiceB (like a proxy), I think it is better to response with 200 OK to the client and wrap the actual results of calling ServiceB to response payload.

For example, like this:

{
  "serviceBresponse": {
    "status": 503,
    ... another information 
  }
}

Semantically it means the following:

Is your ServiceA respondable? Yes, it is. Is your ServiceA was able to process the client request? Yes, it was. What ServiceB responded? See the payload.

Since with this approach you can difer from client perspective which service is actually responded with non-200 status. If ServiceA responded with non-200 status, then the ServiceA was not able to process the request. If ServiceA responded with 200, then you can be sure that ServiceA is okay.

kerbermeister
  • 2,985
  • 3
  • 11
  • 30
  • Just a note: it is not a universal approach, it really depends on a lot of factors, for example, depending on the what the client is. Is it a frontend app, or another backend-service. If you don't want to expose the information about calling ServiceB, then you can simply return 500 status. Just consider your needs. – kerbermeister Feb 27 '23 at 19:40
1

If your API highly depends on Third-Party API, should consider using the HTTP code 503 Service Unavailable along with error message, as your service will be unavailable until the issue is fixed in Third-Party API.

Or if just a small task of your endpoint depends on Third-Party API, can return the HTTP code 200 OK along with error message, because HTTP request to your API was actually successful.

Nasimuddin Bhanej
  • 105
  • 1
  • 9
0

The HyperText Transfer Protocol (HTTP) 503 Service Unavailable server error response code indicates that the server is not ready to handle the request.

Common causes are a server that is down for maintenance or that is overloaded.

Bhupatsinh
  • 36
  • 2