2

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?

migrated from softwareengineering.meta.stackexchange.com Aug 6 at 11:39

This question came from our discussion, support, and feature requests site for professionals, academics, and students working within the systems development life cycle.

  • I'm a little confused on which kind of 404 you think is real. You start by suggesting "real" 404 is one where the path is valid but the id doesn't exist. Later you refer to "real 404s (image isn't present on the CDN)". These seem to be conflicting definitions. – JimmyJames Aug 6 at 18:56
  • Why do you think that "a path where the id isn't present" is not 'technically' an error. You are requesting a non-existent path. The id is part of the path. In what scenario is trying to retrieve something that doesn't exist not a client error? – JimmyJames Aug 6 at 18:59
  • Imagine a scenario when a user goes on your website and enters an email as part of a checkout. You query your API with the email to see if they already have an account, to suggest them to log in and have the data prefilled. I that case, if they don't have an account, you get a 404. Which is not an error. Because it's a natural and expected scenario. But also, if the domain of your call has a typo, you get a 404 which is an actual error. Because an API doesn't exist on this domain. Does this example make it clearer? – Boranas Aug 7 at 16:28
  • If you're querying the API yourself, don't you get to decide what your response to the user is going to be? – Robert Harvey Aug 7 at 16:49
  • Not when you're calling it from client code on the browser. The browser catches 400 level errors and treats them as errors way before they reach your code. – Boranas Aug 13 at 12:18
2

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/?accountemail=foo@email.bar. The accountexists resource will always exist and you can then return whatever you like to describe the existence and/or state of the account.

  • The question doesn't relate to the design of the 404 code and it's not referring to my specific scenario. I've encountered the need to distinguish between a URI isn't reachable and a resource not found countless times. The issue is that once the errors happen, especially on live environments, there is a very different meaning when a client or an app can't reach a path and when the resource is missing. Merging these two behind the same code needlessly complicates the treatment. – Boranas Aug 13 at 12:30
  • And yes. Switching to operation solves the issue. However, the question refers specifically to REST. – Boranas Aug 13 at 12:33
  • @Boranas It's important to define what you mean by REST. Here, I take it mean the general HTTP conventions assigned that name. If you need to stick to that, then the last part of the answer applies. Modify your assumptions and/or approach. The browser gets these errors back. You are likely fighting with a client side lib issue. – JimmyJames Aug 13 at 14:06
-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

  • well... this will be the same as just calling a SOAP method. Not much REST remaining there, right? – Boranas Aug 13 at 12:20
  • HTTP 204 is also a good choice I've found for the scenario of empty response. It knind of solves the problem. But I don't think that's the intended use of 204. – Boranas Aug 13 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.