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.
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!
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.
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?
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/fetc...
401 = Do I know you?
403 = I can't let you do that, Dave.
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.
Successful responses (200 – 299) Client error responses (400 – 499)
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.
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.
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.
This is a very junior take, "I have never used it myself, so it isn't important".
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.
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.
It's not even that complex to do correctly. Usually, it's about 30 seconds of work to just go to https://http.cat/ and pick out the relevant cat.