That’s not what HTTP errors are about, HTTP is a high level application protocol and its errors are supposed to be around access to resources, the underlying QUIC or TCP will handle most lower level networking nuances.
Also, 5xx errors are not about incorrect inputs, that’s 4xx.
…HTTP is a high level application protocol and its errors are supposed to be around access to resources…
I’ve had fellow developers fight me on this point, in much the same way as your parent post.
“If you return a 404 for a record not found, how will I know I have the right endpoint?”
You’ll know you have the right endpoint because I advertised it—in Open API, in docs, etc.
“But, if /users/123 returns a 404, does that mean that the endpoint can’t be found or the record can’t be found?”
Doesn’t matter. That resource doesn’t exist. So, act appropriately.
And it’s not even always a simple case of “that resource doesn’t exist”. A 404 could also mean that the resource does exist but the current authenticated user doesn’t have the correct permissions to access it, so it’s more like “as far as you know that resource doesn’t exist”. Some people might argue that 403 should be used for that, but then you’re telling potential bad actors that maybe shouldn’t even have access to your documentation that they have indeed found a valid endpoint.
Avoiding 403 seems like a security through obscurity approach to me.
I suppose there might be some special admin only endpoints you’d want to 404 on if the user is not an admin. But for most cases it’s really hell integrating an API that 404s on everything… is my token invalid, did I set a parameter wrong, or did I get the path wrong? I guess I gotta spend all day doing trial and error to figure it out. Fun!
Also makes integration tests on your security unreliable. Someone renames an endpoint and suddenly your integration tests aren’t actually testing security anymore. Checking for 403 and getting a 404 because someone renamed something will indicate the test needs to be updated to use the new path. Checking for 404 (because the user isn’t supposed to have access) and getting 404 (because the path was changed) means your test is useless but you won’t know it was rendered useless.
I usually treat a path as a series of dereference operations, each with a potential security precondition. You could protect /secure/… with credential checks, and report 403 at that point, before even looking at the rest of the resource path. It exposes the prefix but not the multiple endpoints that might exist below that point.
The parser in most APIs will automatically handle parsing responses for 400 errors, but if the logic fails due to data being wrong, what do you respond with? E.g you send a valid SSN but the database could not find the person, or you send a valid email, but bo such email was found.
You can send 4xx errors yourself too. If the client needs to change something about the request, that’s a 4xx, like 400 Bad Request. If the server has an error and it’s not the client’s fault, that’s a 5xx like 502 Bad Gateway.
The wikipedia listing of all HTTP codes is quite helpful. People also forget you can send a custom response body with a 4xx or 5xx error. So you can still make a custom JSON error message.
Obviously you can, and i do returm 4xx codes if the initial parsing, authentication or something else goes wrong im the controller, but once im in the next api, or any number of systems down the chain, im probably gonna return a 200 with a status with a tracking code. It’s proven, at least for us very helpful to find issues fast on both sides. To me getting a 4xx back when it’s step 6 our of 13 that is the problem in the API but the request itself is fine doesn’t seem meaningful and just makes customers assume things. I guess if every endpoint only does one thing, i’d probably do like you.
