HTTP 404 for REST calls from client side (browsers)

Question

I'm having troubles with the issue of distinguishing between "real" 404s and 404s where the path is correct but the id, for example, doesn't exist when it comes to client side apps.

Most REST articles and answers here talk about returning a 404 if a resource isn't found. I do understand that a REST URI points to a specific resource and therefore, whether the requested resource isn't there (no such id) or the whole path is wrong, 404 is still the response.

The problem is that browsers tend to treat 404s as actual errors before the request even reaches the app code, which pollutes the console and hides real 404s (image isn't present on the CDN). The second issue is that 400 HTTP codes are described everywhere as client errors. But if the path is correct by an ID is not present, this isn't technically an error. It's proper and expected functionality. It looks akin relying on exceptions for logical flow in the code.

Is there a proper way to handle such scenarios, without spamming the browser console?

Answer 1

We could debate the design of the 404 code and perhaps you could devise some way to differentiate no resource found at a valid path branch. I think though, when you start thinking about other scenarios, this isn't straight forward. What about a URI where the resource is defined by multiple parts of the path that may or may not exist? For example, you could have https://foo.com/resources/<parent>/<child>. The web is designed for everyone, not just your application so the idea that standards should match your exact desires is not realistic.

Regardless, when working in technology, you either need to accept certain things, find an alternate solution, or create your own. It's highly unlikely the way 404 is used and interpreted is going to change for you.

I see a few solutions here. It's absolutely possible to build a web application that doesn't throw a 404 in this situation. You just need a generic HTTP handler. For example, if you drop to something like the classic Java Servlet framework, you have to parse the URI yourself and it's up to you to determine when you throw 404 (and most other errors aside from 500.) You could absolutely return a non-error response when you a request where the resource id is not there. There are surely such APIs in most all languages that support REST frameworks that those frameworks use. You might even be able to customize your REST framework to do as you wish.

Personally, I think you'd be better off accepting this and figuring out how to work with HTTP error codes as they are. No matter how strongly I think driving on the right side of the road is correct (it's literally called the 'right' side), if I'm in the UK or India, I'm sure to have problems if I don't drive on the left.

In what scenario do you expect to have 404 errors for something that is not a result of a missing account? If your base path is wrong, that seems like a fatal error for your client. Or is it simply your understanding that "... browsers tend to treat 404s as actual errors before the request even reaches the app code". If it's the latter, I don't think that's the case. It's not my experience. If you have that issue, I'm guessing its something in a client library. Typically these should offer some way to customize the behavior on errors. You could use that to check for the 404 and intiate creation of the account.

Another option is could modify your API to have a query type operation. For example. have a query parameter like https://foo.com/accountexists/[email protected]. The accountexists resource will always exist and you can then return whatever you like to describe the existence and/or state of the account.

Answer 2

The proper way is return 404 when the path is wrong.

REST is just plain wrong when it comes to using response codes in general and 404 in particular.

Keep a separation between you code and the webserver, return a result or throw an exception and let the webserver decide what the response code should be.

Generally this means returning 200 and json in the body which deserialises to null or an empty list ie nothing, null, [] etc