Putting detailed REST error message in HTTP Warning header, good/bad idea?

Question

We are developing a standard REST service using HTTP status codes as its response code if something went wrong. (e.g. invalid user input would return \"400 Bad Request\" to

Answer 1

I'm in favour of the general approach. We should assume that the client developer is in a different team from the service developer, maybe in a different timezone etc. Possibly even a different company. It's no good just returning a "no that's a bad request" response, how can the client fix the problem.

So philosophically: tell the client about the things they have a responsibility to fix. Errors that are purely the scope of the server (eg. database connection error, or some logical problem) it's fair just to return a 500 error. And here I would not send any detail back, we don't want to expose details of our internal implementation to the client.

Until now I've been returning data in the body of the response, using JAX/RS:

return Response.status(400).entity("some message here").build();

I'm thinking that your use of headers may actually be a cleaner appraoch.