If an http request can't perform the requested operation, should server send 500 error code? Or 200 with status and status message in response?

Isn't 500 used only for unhandled exceptions on server side?

You're right: if you have "planned" the error, no need to return 500, you can "grab" the error and return it properly without causing drama

@Drillan767 thanks. I was suggesting this to one of my colleague who was handling this request on server side.
But the guy who is working on client side, was demanding 500 code. This was because he assumes all failures will be 500. He handles only them.

I had to explain response codes.

@norman70688 Yes. I explained every response code and when to use them.
Colleague was happy that I could make her understand.

Depends on why it can't, if missing data I usually return 422 Unprocessable Entity. But if I get everything null I return 400 Bad Request, or if a query param was missing.

Not sure though if this is the correct approach

@gitpush

I understand response codes 400 and above.

Here the case is, all the params are fine, service is available, network is fine. But an error can happen on server side, even if everything is fine. For example, you've updated an object but there are inconsistencies that you observe while reading due to programming error or environment.

You can only use 200 status code with status and message in response. As far as I understand, 200 is used when server is sending intended response. It could be pass or fail with proper response.

@norman70688 all 400 errors are client errors. Meaning client can correct and re submit, which is not the case here.

@sanjay15693 in that case you are right. Though it is the first time I know 200 can be used for a fail response (intended response)

Thanks for the heads-up

@maushax why do u suggest 403? It's not forbidden.

It's a valid request from valid client. As I mentioned before it's not client side error.

I'm enjoying this conversation.

To give more information on how usually most enterprise products work.

For every known error that can generate on server, there will be and error code with error message. These errors may not be due to client mistakes.

During this case, request will respond with.

Example response:
200 OK. This is to say your Http request is successful.
And response will include something like.

Error code: 156732
Error Message: There is an exception while accessing so and so. Please report to so and so.

Advantages of this.
*) Client knows error is not because of client side mistakes.
*) He/she can check official documentation for error codes related to that product.
*) When reporting issues, along with logs and traces, one can send error code received. This will help back end developers to isolate the issue immediately before debugging.
*) Products can translate such error messages based on locale of client request.

(1/2)

Of course, I understand you can always rely on standard error codes for other standard problems, like 404 for not found, 401 unauthorised etc..

It is better to tell your client, it is not the culprit.

(2/2)

500 causes suspicion and trust issues that is the server really that robust to handle requests