4 ms·

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

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...

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...