3 ms·

> HTTP status codes aren’t worth fussing over. Nope. This article is great, but absolutely no on this one. Specifically even for their 401 vs 403 status code.

> HTTP status codes aren’t worth fussing over. Nope. This article is great, but absolutely no on this one. Specifically even for their 401 vs 403 status code. There are VERY clear definitions for these codes. Please don't goof them up. If you do I will not be able to use your api effectively.

mordae 2y ago
For posterity: 401 = Do I know you? 403 = I can't let you do that, Dave.
guitarlimeo 2y ago
Maybe the author writes those REST APIs which respond with status code 200 but with body `{"error": "Not found", code: 404}`. Half kidding, I also thought the article was great and full of good advice, but share the sentiment that HTTP status codes are great when used correctly!
- candiddevmike 2y ago
  I may be coming around to the always 200 status code. Anytime you start returning non-200s, "intelligent" things in front of your code (load balancers, WAFs, browsers) start doing unpredictable things that are a massive pain in the ass to debug. It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario.
  - guitarlimeo 2y ago
    > "intelligent" things in front of your code (load balancers, WAFs, browsers) start doing unpredictable things I've never had that happen, but instead have had "intelligent" caching mess up my requests that returned 200 multiple times. Granted, most of the times it was a bad header that did not specify no-cache, but as far as I know, error codes are never cached. With 200 and caching, error body would continue to be returned for the cache's lifetime. > It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario. This I agree with, Javascript syntax just sucks for error handling.
  - marcosdumay 2y ago
    Fire your "security" people, hire real security people. The part about making JS fetch errors easier to catch... You consider server errors not to be errors? How is it that telling unreachable servers apart for mother errors better than telling "error" apart from success?
  - nunez 2y ago
    That's a great point. In my limited experience working with AWS API Gateway, sending anything except 200 and 429 causes the gateway to respond with either a 403 or a timeout. Very odd.
  - throwitaway1123 2y ago
    I actually like having a variety of status codes to represent different scenarios. When I'm debugging a request at a glance my mental heuristic is "200-299 means success, 300-399 means redirection, 400-499 means client error, 500-599 means server error". Not sure what you mean about JS fetch calls. The status code doesn't determine wether or not the catch block executes. The only thing it does affect is the value of the response.ok boolean (which is true if the status code is less than 300). There are a few cases where fetch will throw an exception, but status codes aren't among them: https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch#exceptions https://developer.mozilla.org/en-US/docs/Web/API/Window/fetc...
q7xvh97o2pDhNrh 2y ago
Yeah, this one was surprising to me, too. It's not even that complex to do correctly. Usually, it's about 30 seconds of work to just go to https://http.cat/ https://http.cat/ and pick out the relevant cat.
geewee 2y ago
To be fair, I can remember 0 times where as an API consumer I've needed to do different actions depending on whether it was a 401 or a 403 - but I also mainly deal in API->API communication.
- tempcommenttt 2y ago
  I have a production API where sending 401 immediately kills your session and you’re logged out. And 403 doesn’t. We have this as a result of race conditions where the front end incorrectly thinks it still has a valid session. But the back end knows better
  - BWStearns 2y ago
    I like the 401->autokick back to homepage pattern.
- angarg12 2y ago
  As an API provider, it is quite important for me to see if my app is spitting out tons of errors 401 or 403.
ozim 2y ago
Problem is the context for my internal use it might make no sense. Also take into account other tooling. For me context was checking if entity A has entity B available - well 404 is totally valid way to return stuff not found. But in my monitoring tooling 404 was spamming my logs - I changed it to 200 { no-this-entity-does-not-have-B } because in the context of my system it is valid response and not an error.
- titusjohnson 2y ago
  404 is not an error, it's a status code that says "What you asked for does not exist". Why are you worrying about log spam? Why are you monitoring 404s? Now you have an endpoint that lies, how is that better?
  - ozim 2y ago
    No it is not "just status code": Successful responses (200 – 299) Client error responses (400 – 499) https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://developer.mozilla.org/en-US/docs/Web/HTTP/Status I am not monitoring it per se - but all the tooling we use counts it as an error. My endpoint is not lying - request is a question "Is there an entity B linked to entity A" - hence answer is always there and it is either "true" or "false", I am not requesting "give me entity B with Id xyz", that is a different endpoint that can return 404 nor prob.
    - titusjohnson 2y ago
      Obviously I don't know your product, but that just sounds like an endpoint that exposes a join table. Any time I see status code sidestepping, it informs me that something more basic has been skipped earlier. "The monitoring is firing too often because of 404 errors, we should make this endpoint send back a 200 all the time so we stop being bothered by errors that are not errors" reads to me like curing a symptom.
      - ozim 2y ago
        To be more concrete we have 2 separate applications that you can use together. First app can display a link to document in second app if document is there. What we do is checking via API if document exists - show the link to open it. Only if user would try to open the link 404 would be correct. Checking if app should show the link 200 with true/false makes much more sense.
angarg12 2y ago
> but that distinction has never been relevant to my work This is a very junior take, "I have never used it myself, so it isn't important".
marcosdumay 2y ago
What is worse. The author goes to claim that "the computer doesn't care"... The computer handles those in completely different ways. It's a user-visible error to change them, and it will fill your support with complaints from almost every user. People should learn their craft.
DarkNova6 2y ago
Couldn't agree more. Majority of devs only think of FE/BE and think that a good OpenAPI description is not worth the time. It absolutely is, if you factor in a testing team. But they are not mad if you don't think about them. Pretty much nobody ever does after all.

mordae 2y ago

For posterity: 401 = Do I know you? 403 = I can't let you do that, Dave.

guitarlimeo 2y ago

Maybe the author writes those REST APIs which respond with status code 200 but with body `{"error": "Not found", code: 404}`. Half kidding, I also thought the article was great and full of good advice, but share the sentiment that HTTP status codes are great when used correctly!

candiddevmike 2y ago
I may be coming around to the always 200 status code. Anytime you start returning non-200s, "intelligent" things in front of your code (load balancers, WAFs, browsers) start doing unpredictable things that are a massive pain in the ass to debug. It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario.
- guitarlimeo 2y ago
  > "intelligent" things in front of your code (load balancers, WAFs, browsers) start doing unpredictable things I've never had that happen, but instead have had "intelligent" caching mess up my requests that returned 200 multiple times. Granted, most of the times it was a bad header that did not specify no-cache, but as far as I know, error codes are never cached. With 200 and caching, error body would continue to be returned for the cache's lifetime. > It also makes JavaScript fetch calls easier as your catch block will most likely be a hard down scenario. This I agree with, Javascript syntax just sucks for error handling.
- marcosdumay 2y ago
  Fire your "security" people, hire real security people. The part about making JS fetch errors easier to catch... You consider server errors not to be errors? How is it that telling unreachable servers apart for mother errors better than telling "error" apart from success?
- nunez 2y ago
  That's a great point. In my limited experience working with AWS API Gateway, sending anything except 200 and 429 causes the gateway to respond with either a 403 or a timeout. Very odd.
- throwitaway1123 2y ago
  I actually like having a variety of status codes to represent different scenarios. When I'm debugging a request at a glance my mental heuristic is "200-299 means success, 300-399 means redirection, 400-499 means client error, 500-599 means server error". Not sure what you mean about JS fetch calls. The status code doesn't determine wether or not the catch block executes. The only thing it does affect is the value of the response.ok boolean (which is true if the status code is less than 300). There are a few cases where fetch will throw an exception, but status codes aren't among them: https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch#exceptions https://developer.mozilla.org/en-US/docs/Web/API/Window/fetc...

q7xvh97o2pDhNrh 2y ago

Yeah, this one was surprising to me, too. It's not even that complex to do correctly. Usually, it's about 30 seconds of work to just go to https://http.cat/ https://http.cat/ and pick out the relevant cat.

geewee 2y ago

To be fair, I can remember 0 times where as an API consumer I've needed to do different actions depending on whether it was a 401 or a 403 - but I also mainly deal in API->API communication.

tempcommenttt 2y ago
I have a production API where sending 401 immediately kills your session and you’re logged out. And 403 doesn’t. We have this as a result of race conditions where the front end incorrectly thinks it still has a valid session. But the back end knows better
- BWStearns 2y ago
  I like the 401->autokick back to homepage pattern.
angarg12 2y ago
As an API provider, it is quite important for me to see if my app is spitting out tons of errors 401 or 403.

ozim 2y ago

Problem is the context for my internal use it might make no sense. Also take into account other tooling. For me context was checking if entity A has entity B available - well 404 is totally valid way to return stuff not found. But in my monitoring tooling 404 was spamming my logs - I changed it to 200 { no-this-entity-does-not-have-B } because in the context of my system it is valid response and not an error.

titusjohnson 2y ago
404 is not an error, it's a status code that says "What you asked for does not exist". Why are you worrying about log spam? Why are you monitoring 404s? Now you have an endpoint that lies, how is that better?
- ozim 2y ago
  No it is not "just status code": Successful responses (200 – 299) Client error responses (400 – 499) https://developer.mozilla.org/en-US/docs/Web/HTTP/Status https://developer.mozilla.org/en-US/docs/Web/HTTP/Status I am not monitoring it per se - but all the tooling we use counts it as an error. My endpoint is not lying - request is a question "Is there an entity B linked to entity A" - hence answer is always there and it is either "true" or "false", I am not requesting "give me entity B with Id xyz", that is a different endpoint that can return 404 nor prob.
  - titusjohnson 2y ago
    Obviously I don't know your product, but that just sounds like an endpoint that exposes a join table. Any time I see status code sidestepping, it informs me that something more basic has been skipped earlier. "The monitoring is firing too often because of 404 errors, we should make this endpoint send back a 200 all the time so we stop being bothered by errors that are not errors" reads to me like curing a symptom.
    - ozim 2y ago
      To be more concrete we have 2 separate applications that you can use together. First app can display a link to document in second app if document is there. What we do is checking via API if document exists - show the link to open it. Only if user would try to open the link 404 would be correct. Checking if app should show the link 200 with true/false makes much more sense.

angarg12 2y ago

> but that distinction has never been relevant to my work This is a very junior take, "I have never used it myself, so it isn't important".

marcosdumay 2y ago

What is worse. The author goes to claim that "the computer doesn't care"... The computer handles those in completely different ways. It's a user-visible error to change them, and it will fill your support with complaints from almost every user. People should learn their craft.

DarkNova6 2y ago

Couldn't agree more. Majority of devs only think of FE/BE and think that a good OpenAPI description is not worth the time. It absolutely is, if you factor in a testing team. But they are not mad if you don't think about them. Pretty much nobody ever does after all.