|
|
|
Many years ago, I worked at a facility where the phone network, and by extension, the network was maintained by a telecom contractor. The company he worked for decided his performance was subpar and fired him... but forget his hand written notes showed where the connections were.
And... subsequently had to rehire him - he had job security of a sort.
|
|
|
|
|
|
Myst... what memories!
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
|
|
|
|
|
Memories? Nothing special. Just a megabyte worth of good old DRAMS. If my old Atari STs floppy had not died recently, I could dig for Myst in my disk box and start it up.
Now, where do I get an old Epson double density dual sided floppy drive?
I have lived with several Zen masters - all of them were cats.
|
|
|
|
|
I'm wondering, what are your opinions on this.
My current employer uses 404 in web services when some entity cannot be found.
For example, let's say we're trying to get product x, but x does not exist.
Personally, I'd opt for a 200 with an empty response (or a response with a "product could not be found" error).
But here, they return a 404.
Why am I against returning a 404?
Because the server exists, the URL exists, the web service exists, so technically everything was found.
According to Wikipedia "The website hosting server will typically generate a "404 Not Found" web page when a user attempts to follow a broken or dead link;", but the link isn't broken!
I've ran into trouble because I don't want to throw an exception on 404, but I never know if some service could not be reached or if an invalid entity was requested.
In one case I returned the error "Product x could not be found" to a front-end, while in reality the configuration was wrong and the URL to the web service was broken.
I'd understand this on a website, where you browse to mydomain.com/product/x, but a web service?
So... Opinions?
Do you use 404 to indicate that some object could not be found (in a web service)?
I get that we did not find product x, but there must be a better way to separate functional from technical error...
How do you handle this?
|
|
|
|
|
I'd have to that that from a user perspective, a 404 normally means "oops! I moved it" and that it might come back if I retry in an hour or so.
A specific "that product cannot be found" means "the Elephants don't stock that anymore" and I'll look for an equivelant, or go elsewhere to someone who does.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
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: 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
