4 ms·
HTTP error codes are something of an embarrassment to the web. We have more codes for April Fools jokes than some of our most common situations we deal with. W
by neilellis 11y ago
HTTP error codes are something of an embarrassment to the web.
We have more codes for April Fools jokes than some of our most common situations we deal with. We have some bizarrely specific codes like Payment Required and Requested Range Not Satisfiable yet almost all real world application responses get dumped into 400, 500 and a few other codes.
How about more specific and useful codes like:
Parameter not Supplied, Parameter Name Invalid, Parameter Value Invalid, Url Path Invalid Format, Could Not Parse Data etc. etc.
This would also allow client libraries to decide better on how to process errors (i.e. as application or systemic errors).
I'm sure folk have better suggestions than I but I can't imagine many folk genuinely feel these existing codes are expressive for the modern (API centric) web.
- joshstrange 11y agoAgreed, the codes are a crap-shoot. We are working on a redesign of our API and I've pushed for always returning a 200 with a defined JSON structure of something along the lines of: { "status": true "data": { ... } } for success and { "status": false "errorCode": 123, "errorMessage": " ... " //Only shown in dev/debug mode } for failures. We haven't nailed it all down yet but there was no way I was going to do HTTP status codes for some things and some JSON errorCodes for others. It needed to be all or nothing and since HTTP codes obviously wouldn't satisfy it was 200's everywhere...
- RussianCow 11y agoThis is what we do as well. As an added bonus, it makes writing client libraries for our API easier since error handling is more consistent. (Many HTTP libraries handle error status codes differently than 200s, which is annoying since you now have to handle errors in two places.)
- neilellis 11y agoI think for application status codes it makes sense to always return 200 and do as you have done. Of course, if your API has received bad data then better to return a 400 and a similar payload. And if your application has caught an exception which is not part of any form of validation then better to return 500 and the payload. Got to do the best we can with the hand we're dealt hey!