I get it. I’m just trying to illustrate why i like to differ between com and app errors. Now we have identified three different scenarios, all returning 404.
Resource not found
Data not found (client error).
Data not found (server error).
when we could treat them different because their nature is fundamentally different.
I mean if we request a list of objects and nothing was found, because we asked for a date when there was no data, its not an error. But i suppose many still just throw around exceptions still instead of handle them properly, and it looks terrible in the log. Imo if i know the reason for a behaviour its not necessarily an error, and using an error code for a non-error makes it harder to find real errors. Maybe i’ve just been turned off by how they have been used in our legacy code. Maybe you don’t define 404 as a client side and not an error, and i guess thats fine. But its pretty counterintuitive to be a number in a list of client errors and be anyrhing but.
Resource not found Data not found (client error). Data not found (server error)
they are all the same thing; there is no useful, practical distinction between them
if we request a list of objects and nothing was found, because we asked for a date when there was no data, its not an error. But i suppose many still just throw around exceptions still instead of handle them properly
it’s an empty array: not found when requesting something specific is an error… that’s different to here is the complete set of 0 objects… like like if you have an array and request an index that doesn’t exist you get an exception, but that doesn’t mean an empty array is exceptional: it is in fact very valid
using an error code for a non-error
well, it is an error though. you have requested a URI for an object that doesn’t exist: it doesn’t matter whether it’s a resource or an individual thing
remember that HTTP youre asking the server for some object matching a URI: please give me the object matching /users/bananoidandroid and /userssssss/bananoidandroid may both not be found for the exact same reason: the object referenced by that string does not exist
here’s the spec definition for 404
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent. The 410 (Gone) status code SHOULD be used if the server
knows, through some internally configurable mechanism, that an old
resource is permanently unavailable and has no forwarding address.
This status code is commonly used when the server does not wish to
reveal exactly why the request has been refused, or when no other
response is applicable.
when you’re dealing with specs, deciding not to follow them because you feel like they’re wrong is not appropriate… this leads to bugs and issues in compliant tools because they make assumptions about what things mean
200 means the thing that you asked completed successfully
here’s the definition of 200:
The request has succeeded. The information returned with the response
is dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent in
the response;
HEAD the entity-header fields corresponding to the requested
resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the
end server.
*edit: when talking about compliant, standard tools the classic example is transparent cache: a GET should not transform the resource and thus a GET with response of 200 can be cached… an API that uses a GET to modify a resource may cause transparent proxies (or CDNs) to significantly mishandle the user request… same goes for 200 vs 4xx and 5xx: proxies know that 200 means what it means and may cache based on that, where 5xx should never be cached and 4xx is probably dependant on which specific 4xx
Of course there is. Maybe in your line of work and set of “standard” tools there is no distinction, and everything is a world of simple rules. For me, handling an error based on a response is what you are supposed to do.
If you do not differ between them, you’ll just spend time to figure it out by hand.
I get it. I’m just trying to illustrate why i like to differ between com and app errors. Now we have identified three different scenarios, all returning 404. Resource not found Data not found (client error). Data not found (server error). when we could treat them different because their nature is fundamentally different. I mean if we request a list of objects and nothing was found, because we asked for a date when there was no data, its not an error. But i suppose many still just throw around exceptions still instead of handle them properly, and it looks terrible in the log. Imo if i know the reason for a behaviour its not necessarily an error, and using an error code for a non-error makes it harder to find real errors. Maybe i’ve just been turned off by how they have been used in our legacy code. Maybe you don’t define 404 as a client side and not an error, and i guess thats fine. But its pretty counterintuitive to be a number in a list of client errors and be anyrhing but.
they are all the same thing; there is no useful, practical distinction between them
it’s an empty array: not found when requesting something specific is an error… that’s different to here is the complete set of 0 objects… like like if you have an array and request an index that doesn’t exist you get an exception, but that doesn’t mean an empty array is exceptional: it is in fact very valid
well, it is an error though. you have requested a URI for an object that doesn’t exist: it doesn’t matter whether it’s a resource or an individual thing
remember that HTTP youre asking the server for some object matching a URI: please give me the object matching /users/bananoidandroid and /userssssss/bananoidandroid may both not be found for the exact same reason: the object referenced by that string does not exist
here’s the spec definition for 404
when you’re dealing with specs, deciding not to follow them because you feel like they’re wrong is not appropriate… this leads to bugs and issues in compliant tools because they make assumptions about what things mean
200 means the thing that you asked completed successfully
here’s the definition of 200:
*edit: when talking about compliant, standard tools the classic example is transparent cache: a GET should not transform the resource and thus a GET with response of 200 can be cached… an API that uses a GET to modify a resource may cause transparent proxies (or CDNs) to significantly mishandle the user request… same goes for 200 vs 4xx and 5xx: proxies know that 200 means what it means and may cache based on that, where 5xx should never be cached and 4xx is probably dependant on which specific 4xx
Of course there is. Maybe in your line of work and set of “standard” tools there is no distinction, and everything is a world of simple rules. For me, handling an error based on a response is what you are supposed to do. If you do not differ between them, you’ll just spend time to figure it out by hand.