3 ms·
Because the HTTP error codes simply don't cover the errors of actual applications? So you end up returning the real error code in the body anyways. Now client a
by MichaelGG 12y ago
Because the HTTP error codes simply don't cover the errors of actual applications? So you end up returning the real error code in the body anyways. Now client apps need to check two different places for errors. (For instance, what's the error for "request can be completed but not with the price restriction you've set on your account" vs " request can be completed, but not for the price we've committed to", and "request cannot be completed because we don't have any available prices". That's three real errors we had to return over SIP, which takes the HTTP error model. You know what everyone does applying to billions of calls per day? Send back 503 on basically everything, except busy which happens to have it's own useful code.
- allendoerfer 12y agoWhat about 402 or 409? But that was not really what I meant. In your case, it does not cost the API-owner anything to use 503 instead of 500, he has to provide an additional message anyway. If instead a more common error occurs, it is just nice for the client to get a standard status code, that is known by frameworks and libraries and can potentially already be handled at that level. Just because something can not be standardized entirely does not mean you should not standardize parts of it.