4 ms·
You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may n
by speedplane 9y ago
You don't even need that. I don't think there is anything wrong with returning a 200 response with a JSON body that has some 'error' tag built into it. It may not be purely RESTful, but if it's obvious to the developer interacting with the API, who cares.
- fleetfox 9y agoWhat a horrible advice, just because you are too lazy to return correct status code someone who consumes the api has to do twice the work.
- speedplane 9y agoNot at all. Some languages and libraries don't handle non-200 status codes nicely, they may raise exceptions for each code, or maybe not. For example, Python's basic urllib library makes it easy to get 200 responses but a hassle to get anything else (you need to wrap it in a try/except). For some APIs, it definitely does make sense to use proper status codes, but for others, it's like fitting square pegs into triangular holes.
- merb 9y agowell most consumers work better with 400 errors. (i.e. angular1 or even angular2 where the 4xx error codes will be inside the error clause of the promise/observable)
- speedplane 9y agoThere are probably hundreds of http clients, not sure if "most" handle error codes elegantly, I know that python's base urllib library does not.
- IanCal 9y agoThat means I can't use any kind of generic retry / back off code because I've now got to start dealing with your custom errors, and if you have html versions of the info Google will start demoting you. Just add a code, it's seconds of work.
- speedplane 9y agoYou're assuming you want your API to work with a specialized crawler, like Google-bot. If that's important, then sure, design your API so Google-bot can crawl it nicely, but then it's Google designing your API, not you.
- kiallmacinnes 9y agoI think you missed his primary point. By doing what you describe above, generic client side code to handle retries/backoff etc etc is rendered useless. Your users now have to implement something custom for this (and, if your doing network operations and DONT do this, you likely don't have a very robust system).
- IanCal 9y ago> You're assuming you want your API to work with a specialized crawler, like Google-bot. Not really, I just don't In general, the key point as about working in a generic way, given that it's so simple. I don't like the idea of returning a human readable message that says there was an error but a machine readable message that says everything was fine. I have far too many cases of having to deal with human text explaining that a value is missing already in my data.
- kiallmacinnes 9y agoI disagree, at a minimum, use 200/400/500. Each grouping of error code defines semantics which are implemented by generic clients / servers / middle boxes / monitoring agents etc. These are things out of your control, and often ran by a range of different companies. Debugging these is .. hard.
- snarfy 9y agoYep and when I have to investigate production issues, you're the guy that makes me do slow wildcard queries of the detailed error text instead of just filtering on the (indexed) response code. You push your laziness onto the rest of the world that way.
- speedplane 9y agoI actually agree with your sentiment, but disagree with your characterization that it's "laziness"... how about not knowing?
- snarfy 9y agoYou're right, that's most likely the main offender. Apologies. I've been consuming a lot of poorly written REST apis lately and am bitter.
- dsego 9y agoThe worst one I worked with recently would return 200 and only a human readable error message (no status). On top of that the message is sometimes phrased differently. Here is an example from memory: "The field email is not valid." and "You provided an invalid username."