|
OriginalGriff wrote: I'd have to that that from a user perspective, a 404 normally means "It don't work, feez eet!" FTFY
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
A further thought: if I get a 404 and it doesn't "come back later" then I assume the site was written by idiots, or isn't maintained - and I bugger off elsewhere anyway.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Odd - another direct reply, aside from TOTD.
OriginalGriff wrote: and I bugger off elsewhere anyway. Thank you ! You just heralded an epiphany!
People with multiple personality disorder are easy to please!
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
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).
|
|
|
|