4 ms·
Hard to get behind an argument on status codes being pointless when the article itself cites the usefulness of wisely chosen status codes, such as "201 Created,
by TheAndruu 11y ago
Hard to get behind an argument on status codes being pointless when the article itself cites the usefulness of wisely chosen status codes, such as "201 Created, 429 Too Many Requests, and 503 Service Unavilable".
I've created and used many a RESTful API and can vouch the ones that just return 200 even in cases of error are a big pain in the neck.
This is usually done (IMO) as a shortcut on the hand of the service provider, lack of knowledge on the conventional codes that should be used, or for the sake of more flexibility when endpoints change.
However, all of those reasons just push more work onto the service consumers. Lack of standardized status codes means the consumer must have customized error detection, which is more susceptible to changes as the provider pushes out updates.
- nitrogen 11y agoI've seen APIs that always return 200 because the iOS app that was the API consumer couldn't handle non-200 responses (something about it being harder to get the response body IIRC).
- oxguy3 11y agoDunno bout iOS but I know Java's built-in HTTP library requires you do something like `if (status<400) { stream = getResponseStream() } else { stream = getErrorStream()}`. It's so silly.
- paulddraper 11y agoYeah, Java's HTTP stuff is barely usable. If you are doing more then playing around, use singing better. Apache httpclient is a very well constructed library. And there are bunch of other smaller ones.
- anExcitedBeast 11y agoHTTP status codes are also useful for infosec people during breach investigations. Sometimes all that's available is access logs, and those codes can provide a lot of context.
- TheAndruu 11y agoGood point. They're also critical for any HATEOS applications
- yaur 11y agoIts an IE/Edge thing. Error messages < 512 bytes will get eaten by the browser and replaced with a standard error message.
- tracker1 11y agoOne that bugs me, is IIS with .Net projects, such as WCF where condition validation fails returns a 500 error, instead of a 400... I've come to implement a global exception handler to inspect the exceptions to handle these things, so only actual server-side errors return 500... others will wrap out. Mainly because I got tired of seeing certain classes of errors showing up in my main error logs, when they are being caught, but throwing 500 errors... mainly pen-test/bots trying to get in.