Using HTTP headers to report error response returnd by a REST API

[yakbuttercandle]

Re: https://blog.apigee.com/detail/restful_api_design_what_about_errors

What about using x-error-message and x-error-code and x-error-resolution headers and a null body to report error message when response status is not 2xx? With this approach, client-side json parser need not have logic to parse the response status code. 

[Jack Repenning]

On Mar 13, 2015, at 12:02 PM, yakbuttercandle <ganesh.rama...@gmail.com> wrote:

Re: https://blog.apigee.com/detail/restful_api_design_what_about_errors

What about using x-error-message and x-error-code and x-error-resolution headers and a null body to report error message when response status is not 2xx? With this approach, client-side json parser need not have logic to parse the response status code. 

There still needs to be some logic, somewhere, parsing something. I'm not clear why a pre-supposed "client-side JSON parser" would be greatly inconvenienced by fetching a field out of the JSON body (which, most likely, has already been transformed into a dictionary by the client's interface library). I'm probably hampered, in thinking about it, by imagining it through Rails-colored glasses, where we'r just talking about the name of the pre-defined dictionary object we subscript to get the info. Maybe you could expand on the use pattern in your mind?

Your linked blog is a bit long in the tooth. If you're going to invent an error-return format anyway, I'd suggest "HTTP Problems," 

  https://tools.ietf.org/html/draft-ietf-appsawg-http-problem

True, it's still only a draft, but even at that it's better known, and more thoroughly reviewed, and maybe even better thought out than anything  you or I might dream up next Tuesday, or copy from some API that existed to be cited in a 2011 blog ;-)

-- 
Jack Repenning
Repenni...@gmail.com

[Chris Mullins]

I would suggest NOT using the "x-" approach for headers. That's been pretty clearly demonstrated to be non-ideal, and the approach has been (IIRC) officially deprecated.

The question would be, why would you want to remove error handling from your client side JSON code? That seems like a big feature, rather than something to avoid.