Which HTTP status to return if a downstream service I depend on returned 500 error

Question

My service B is part of a chain of services and calls a downstream service C.

A --> B --> C

Service C is returning HTTP 500 errors for any error it faced, including bad requests or input validation errors that normally should be 4** errors.

There is no option to change / update service C.

Since service B is stuck between the calling application A and service C, there are many occasions that service C will return HTTP 500 only because the input params sent by A are wrong.

As the writer of service B, I'm not aware of the different validation service C will do on the input and I definitely don't want to duplicate them in B.

I wonder what should be the best HTTP error code to return when C returns 500? At the moment I can't differentiate between real server error or bad input.

The problem with return whatever C returns to you is that whenever my service returns 500 error, we will need to start debugging and understanding if the cause of the error is from B or it is just a propagation of the error from service C.

Answer 1

The problem is not the status 500, but the fact that you receive an inappropriate status 500.

Assuming that the client is aware of the situation, you could return status 500 plus a message that this is caused by service C. But if you can figure out what the correct status would have been, return that.

So your client will receive: Correct status codes from your server, including sometimes an appropriate status 500. Or a status 500 marked as “caused by C”. Or some other status, created by you to replace a status 500 from C.

Answer 2

From the point of C you should send valid data to get a successful response. If it answers back with 500 it is an issue for C. If you know what the valid request looks like then you can validate the data in B sent by A and inform the client about the validation error. In case when the client data is valid, send it to C and get the expected result.