Re:Some items from my “reliability list”
by hathawsh on Thursday July 25, 2019 @04:04PM
(#20529015)
For the HTTP API my company has been building, we're returning 400 status codes for most errors. It is intended as a strong suggestion that client code needs to handle errors rather than ignore them. However, we're aware that some client libraries are limited in their ability to handle status codes other than 2xx, so we allow an optional request parameter that asks the server to return 200 instead of 400 for most errors. As you said, smart people disagree about this, so we let them choose. I think we've hit a good balance.
[ Parent
| on HN ]
Re:Some items from my “reliability list”
by DreamSpinner on Friday July 26, 2019 @01:07AM
(#20532492)
That sounds like an excellent approach. If a consumer chooses "always 200 on error", how do you return the API response status? HTTP Response Header or in a custom value in the response body?
Thanks. Error responses from our API always generate a JSON object with top level error and error_description attributes, while non-errors never contain a top level error attribute. It might be interesting to add a response header to disambiguate even more.