4 ms·
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
by hathawsh 7y ago
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.
- DreamSpinner 7y agoThat 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?
- hathawsh 7y agoThanks. 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.