Invalid data returned, which HttpCode to return?

Question

My web application calls a third party API.

If I successfully call the API but invalid data is returned which cannot be processed by my system what is the most appropriate HttpCode to return to the user calling me?

• 500, I'm not convinced. Although it was an internal error it's due to external factors
• 503, Perhaps, although very vague
• 400, 4XX errors are usually related to the client contacting our server and so could be misleading.

Which is the most appropriate response to return to my client?

• Mahdi: So the third-party API waits for you to output an HTTP status code? If yes, you have to look at their API documentation to see how to handle it. Here it doesn't matter what you prefer, take a look at their API and choose a proper status code.
• Liath: @Mahdi it's more the status code I return to my user (which I can define). I've updated the question to try to make this clearer
• Mahdi: Yes, I see. In that case I will go for 500, however your users might blame on you for the error. I'd output a proper page -- 200 code, informing them about the third-party call failure and will ask them to try it again later.
• Bart van Ingen Schenau: For your clients, how relevant would the difference be between an internal error in your implementation or an error due to external factors?
• Brian: @Mahdi There's nothing stopping a 500 error from including content with more information.

Answer 1

If the problem is not the user / client's fault then your server should return a 5xx error. A 4xx error should only be returned if the>>request<< is incorrect in some way.

Depending on the situation, either 500 or 503 could be appropriate:

• As far as a client is concerned the "external factors" are internal to your server / service. So 500 could be appropriate.

• If the problem is likely to resolve itself (or be resolved) in a relatively short period of time, 503 could be appropriate.

Probably either of those is OK.

Another possibility is to return a non-standard 5xx code. Note that non-standard (i.e. not defined in the HTTP 1.1 spec) status codes are not wrong. There is ample precedent for doing this ... including the precedent of other RFCs defining extra codes; see the Wikipedia List of HTTP Status Codes for examples.

---

I noticed a comment suggesting this:

In that case I will go for 500, however your users might blame on you for the error.

Provided that you include details of the cause of the problem in the 500 response body (in an appropriate format!), that should not be a problem.

I'd output a proper page -- 200 code, informing them about the third-party call failure and will ask them to try it again later.

IMO, that is incorrect. A 200 code means that the request has succeeded ... which it patently hasn't. Assuming that this is a RESTful service, the client is going to use the status code to decide what to do next. It should not be a lie. If you want to say "try again later", you should send a 503 response, possibly with a Retry-After header.

• Liath: I think you're right - whether we expect the issue to resolve itself (unavailablity) is the key factor

Answer 2

Do you mean the server returns incorrect data, or data that is correct but unexpected to you and that you cannot handle? The server obviously should never knowingly return incorrect data, so if it ever returns incorrect data, I would expect them to come with a status 200. Meaning the server thinks everything is fine and doesn't realise its error.

If the server has found data to return but figured out by itself that the data is incorrect, then it is a server error (internally in the code producing the data, which has failed), so some variation of the 500 status should be returned.

Answer 3

I'm also confused about using 500, 502 or 503, may be 502 is best, like 502 Server Error: The server encountered a temporary error and could not complete your request

502: "Bad Gateway." This error code typically means that one server has received an invalid response from another, such as when a proxy server is in use.

see HTTP Status Codes: A Complete Guide & List of Error Codes

and How To Fix a 502 Bad Gateway Error (13 Quick Fixes)