|
Quote: The HTTP 404, 404 Not Found and 404 (pronounced "four oh four") error message is a Hypertext Transfer Protocol (HTTP) standard response code, in computer network communications, to indicate that the client was able to communicate with a given server, but the server could not find what was requested.
So 404 is the most perfect solution for anything not found in a chain of web request... Not only things related to the server and the resources on it, but also for data related resources... However you may alter the text, it will give two things:
1. 404 is understood by non-human client too
2. Altered text can refer to human client to what exactly the problem...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
When should 404 be returned according to you? It can't be when the server does not exist - because then it can't response. It can't be when the URL is malformed - that would be a bad request.
404 means exactly what it says on the tin: I looked at the location you specified, and I did not find anything - i.e. what you asked for was NOT FOUND.
What you are missing is proper logging and health monitoring. 
|
|
|
|
|
lmoelleb wrote: When should 404 be returned according to you?
You're right about the server, of course, and probably also the domain, but when you're trying to call a controller or function that doesn't exist it should return a 404, for example https://www.codeproject.com/something[^].
I agree that when the function exists, but returns no result a 404 might be appropriate, but it becomes a hassle to differentiate between "function does not exist" and "whatever you're looking for does not exist".
So what should a search form return if a user searches for the (human) name "123"? 404 or 200 with no results?
I'm saying 200, because everything went well, but there is simply no person with name "123" (which is also a valid response)
|
|
|
|
|
Well, it did find the search result - it was an instance of an empty list which it returned, so 200 with an empty response it is. 
REST return values are indeed problematic, as is often the case when something is repurposed well beyond the initial design plan (that would be all of HTTP/HTML pretty much). But your original example was not one I would throw into the "problematic bucket".
|
|
|
|
|
Tomato tamata...
I think it all comes down to the protocol that has been agreed upon between the consumer and provider so to speak.
If you use Swagger you can document this for the consumers - so in the end I don't think it matters too much.
Personally I would return a 200 with some info in the body.
That said, a 404 can be useful for blocking hacking attempts as it gives hackers the impression that the endpoint does not exist.
Tomato tamata...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
We are using a 404 response code for a very similar scenario in Azure functions. But we also log when we send back a 404 with a proper message of what went wrong. For instance, "The product {x} was not found." in your case.
So yeah, 404 seems to be the appropriate response as pointed out by @KornfeldEliyahuPeter and @lmoelleb.
I am not the one who knocks. I never knock.
In fact, I hate knocking.
|
|
|
|
|
200 OK is in any case wrong, but you have to decide whether this is a Client error or not.
All responses in the 400 category are Client Errors.
If it's not a client error you should consider 204 No Content
|
|
|
|
|
When you are asking a server for a resource you issue a GET with the URI of the resource. If you're looking for a file called home.html you would issue
GET /home.html
If that resource can't be found the server will respond 404 to let you know.
When you are asking a web service for a resource you issue a GET with the URI of the resource. If you're looking for a Product with id of 123 you would issue
GET /product/123
If that resource can't be found the server will respond 404 to let you know.
In the first case the resource is a file, in the second the resource is the product.
You're not thinking about the resource itself, you're thinking about the mechanism to deliver the resource. The fact that the /product controller exists means the mechanism to find the product exists, but the client isn't interested in that, it doesn't care if the delivery mechanism is there, it cares if its product\resource is there. When you ask for
/thisdoesnotexist.aspx
if we return 200 because the mechanism to deliver the resource exists even if the target resource doesn't then this would return 200 also as the http handler that deals with the aspx pipeline exists, even if it can't fine the relevant aspx file on the file system.
|
|
|
|
|
You do make a valid point.
I'm still not sure how to gracefully differentiate between "URL not found" and "Product not found".
In my specific case I'm calling a web API that returns a 404 when a product isn't found.
However, I need to report 400 "product not found", along with other error messages.
In my case a 404 URL not found is more like a 500, I'm calling a URL that doesn't exist.
In some other service I have to try and parse the body, if it's a string it's probably an error, else it's a valid request.
All those if-elses don't feel very nice though...
|
|
|
|
|
The title for 404 is "Not Found".
It is agnostic as to what type of resource is being requested; could be a product, a category, a page, or something else.
In my world...
- The message returned would be based on the context of the path; if it is a product endpoint then I would say "Product Not Found". Likewise if it was a Category I would say "Category Not Found"
- In the above example, if I know the product existed (e.g. via a ProductID) and had been deleted, I would return a "410: Gone" status
I suppose a 400 could be used if the requested path was invalid; such as "domain.com/retrieve/porduct/101" as the mis-spelling could be viewed as being an example of malformed request syntax
Unless there is a system exception that is not being caught; I do not return 500 errors.
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Talking about desktop development, I always feel uncomfortable to format hard disk, when user types out-of-range value in some textbox.
|
|
|
|
|
No one was talking about desktop development...
But formatting a disk sounds like a good plan, maybe we should implement that on our back-end too! 
|
|
|
|
|
Actually, I share your feeling that 404 is too much for "Product x could not be found" case. But probably my sarcasm was not clear without smiles, I don't like them (old school). So, these smiles provide required emotions for my both posts: 
|
|
|
|
|
Sarcasm and such are hard to convey on the web 
I get your point now though 
|
|
|
|
|
(Tangent thread)
You could use ⸮
|
|
|
|
|
|
We’ve just had exactly that discussion at CodeProject.
404 means “The server has not found anything matching the Request-URI”
This doesn’t only mean it can’t find a page. It also means it can be used if it can’t find a resource corresponding to the URI. It’s used when you want to say ‘can’t find it but I’m not going to give you any further info on why’
cheers
Chris Maunder
|
|
|
|
|
Exactly. What is being requested (the resource) is not of any particular content-type.
The great philosopher Obi-Wan Kenobi in essence returned a 404 when he stated "these aren't the droids you're looking for"
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
Not the best example as master Kenobi was lying at the time, were he a web service he should've returned a 200
|
|
|
|
|
How about code '204 No Content'?
I would say based on the definition it is closest to your case...
|
|
|
|
|
I agree that 404 seems wrong in the sense that the service has been found; it's just the data's not there.
Taking a quick look on SO it seems 204 is the most popular choice of code for where the service is found, but there's no data: rest - HTTP status code for "no data available" from an external datasource - Stack Overflow[^].
A 200 with empty result set makes sense if you're returning a list in some contexts; e.g. if I want all students attending a course and provide a valid id for the course but there are no students allocated, I'd want an empty list. If the course id was invalid I'd want an HTTP error (probably 204 as per SO link above).
If searching for a single item and it's not found, a 204 makes sense (i.e. presumably I'm searching by ID / some unique field as I know that I only expect a single item, so I'm expecting that single item to exist; thus it's an error if it does not).
|
|
|
|
|
Lets try an analogy, which might not translate, but lets give it a try.
This mainly based on the comment
Sander Rossel wrote: Because the server exists, the URL exists, the web service exists, so technically everything was found.
So lets change this mydomain.com/product/x, to a physical building.
You are asked to go to Building MyHouse, Floor 3, Sales Room and get Document Sale#123
What is the important part of that request? The Document.
So you go to MyHouse, it exists. Good start! Oh, and it has a 3rd floor, which indeed has a Sales Room.
Now there is a stack of papers in the middle of the room. No furniture. That costs money.
You look through the stack but do not find Dcoument Sale#123.
It is not found. It may have never existed. The number might be wrong. someone might have deleted.
Many possible reasons, but for the request, it is not found.
In contrast, I have implemented in a web service 404 if id not found, but if found and query for date range where empty amount of results, returns an 200 empty array. That data at some point may be generated.
|
|
|
|
|
I'd do what you've suggested - a 200 with an empty response.
A 404 doesn't feel correct to me. To me that indicates that the web service was not found.
|
|
|
|
|
I recall reading in some news letter or email notification I get, that the IETF are actually considering adding an official status code to the HTTP spec, specifically for this reason.
Iv'e just had a look through the RFC List (RFC HTTP Index by Date) however and I can't see anything that jumps out at me.
The last official update to the established status codes was back in 2012, and that was only a handfull to communicate header size preferences and stuff
In my mind though, 404 in this scenario is perfectly valid, Iv'e used it a bunch of times, but with a small caveat.
I do what IIS does.
Everyone's seen the 404.3 that IIS throws back at you when you ask it to download a mime type it's not yet had configured correctly?
Well, why not use sub codes?
Many sub codes are free to be used as you see fit 404.3 is for example afaik not an official allocation anywhere.
There is however one small point no one here has actually brought up yet...
Is this a page request or is it an ajax request?
If it's a page request, that is /foo/bar/123 is expected to bring back a visible page change, then I understand the need to get this right, BUT, if your using something like angular , vue, aurelia etc then really what does it matter what your status code is?
In the case of an Ajax request the ONLY thing that should see the response code is the client code running in the browser, not the end user. So if you feel that sending back a 404 to what's essentially (or should be) invisible to the user of the web application, then a 404 is basically whats needed, given that all your doing is telling your own code that entity was not found.
Shawty
|
|
|
|
|
It depends. If the request is coming to /api/resource/{id}, then it's a 404. The spec states:
Quote: 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.
If it's as the result of parameters (/api/resource/?foo=bar), then I'd give a 200 and an empty result.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
