5 ms·

I agree with pretty much all of this. We developed an API because we had desktop/mobile/website. They all use the same API. I call it REST-ish. I can't see

by sbov 11y ago

I agree with pretty much all of this. We developed an API because we had desktop/mobile/website. They all use the same API. I call it REST-ish. I can't see how people think returning 404 for a "this product doesn't exist" is defensible. You now have two different things intertwined: this product doesn't exist (generally not a huge deal - what if an end user manually edits the url on your storefront?), and this url makes no sense (a huge deal - something is broken). If you had code that threw the same exception when a product didn't exist vs when the table in your database doesn't even exist you would be ostracized. I don't see how it's somehow OK because it's REST.

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 ago
  Agreed, 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 ago
    This 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 ago
    I 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!
harryf 11y ago
> I can't see how people think returning 404 for a "this product doesn't exist" is defensible. To tell Google for example to stop sending traffic to this URL because it's gone.
- sbov 11y ago
  Is this a thing? Having Google index your REST api?
- RussianCow 11y ago
  Which isn't relevant with regards to APIs.
dragonwriter 11y ago
> I can't see how people think returning 404 for a "this product doesn't exist" is defensible. Because that fits perfectly the definition of a 404. > You now have two different things intertwined: this product doesn't exist (generally not a huge deal - what if an end user manually edits the url on your storefront?), and this url makes no sense (a huge deal - something is broken). Arguably, the "this URL makes no sense" case is a better fit for a 400 [0] rather than a 404 [1], so those two cases need not be conflated even when using a 404 for the "this product doesn't exist" case. [0]: "The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." [1] "The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists."

by sbov 11y ago

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 ago
Agreed, 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 ago
  This 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 ago
  I 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!

harryf 11y ago

> I can't see how people think returning 404 for a "this product doesn't exist" is defensible. To tell Google for example to stop sending traffic to this URL because it's gone.

sbov 11y ago
Is this a thing? Having Google index your REST api?
RussianCow 11y ago
Which isn't relevant with regards to APIs.

dragonwriter 11y ago

> I can't see how people think returning 404 for a "this product doesn't exist" is defensible. Because that fits perfectly the definition of a 404. > You now have two different things intertwined: this product doesn't exist (generally not a huge deal - what if an end user manually edits the url on your storefront?), and this url makes no sense (a huge deal - something is broken). Arguably, the "this URL makes no sense" case is a better fit for a 400 [0] rather than a 404 [1], so those two cases need not be conflated even when using a 404 for the "this product doesn't exist" case. [0]: "The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)." [1] "The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists."