|
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.
|
|
|
|
|
I had been using 404 when I also had the same trouble that you did and also read the same article that you did.
So now I return 200 and an empty data object.
It is easy to check the object for being empty, if I want to display an appropriate message or take some particular action.
There are no undesirable error messages popping up.
I explained this to my supervisor and he agreed.
-- modified 22-Feb-18 9:51am.
|
|
|
|
|
Just an non-technical opinion: Be pragmatic, => https://en.wikipedia.org/wiki/Pragmatism
…and do as your employer says.
Think in your anal annual review, it will say “...grasps concepts quickly”  instead of “… needs improvement on taking orders”  .
Experience has teach me that I don’t have to lose my mind in minor details because every single employer sometimes will have a crazy idea and somehow they think that my “loyalty” is in doubt if I don’t do the same way they planned.
BUT, you have to be aware of “suicide ideas”. i.e. ideas from your employer that will jeopardize either profits or real world operations. Then you have to show your point of view with clear numbers although finally they implement that suicide idea. In that case of frustration I recommend a couple of Samuel Adams or Molson Canadian.
Crazy ideas (manageable ones) => Ok, do it. (Even when they sound a little crazy)
Suicide ideas => Show clearly your point of view. (but don’t lose your mind if you are requested to implement)
Only my humble point of view. ![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Sometimes I feel like no one reads the specs. The HTTP spec is one of the shorter ones too.
Forget about Exceptions, that's just your framework letting you down. An HTTP status code is not an exception or a technical error it's a status code. Using exceptions for that is like throwing an integer instead of an exception. The exception to this is when it's a technical error - those errors are in the 500s.
URL means uniform resource locator. That means it's the string(usually) that can be used to locate some resource. You your URL of mydomain.com/product/x is the locator for product x then the status code should reflect that. If the product has never existed then you should return 404, if you've moved it you should return 301, and if you've permanently deleted it then return 410.
|
|
|
|
|
Reading the definition of a 404:
The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible.
It literally says the RESOURCE, which I assume is what you are looking for, cannot be found.
I see how it could be confused with a MALFORMED request: "site/admn/XXX" instead of "site/admin/XXX"
But that should be RARE when implementing an API. And it has to be debugged.
I do not see an appropriate code to return otherwise.
Now, when we deal with a call to returns no data. We literally return 0 rows of data (I just checked).
And yes, the code is cleaner. A 404 starts to imply there is a SERVICE issue.
Hmmm, now it boils down to whether this is an EXCEPTION or not. In our API, ZERO results is NOT an exception.
|
|
|
|
|
Sander Rossel wrote: 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?
Technical errors are 500.
User isn't going to fix it and it isn't likely it is going to fix itself.
But other than that doesn't matter to me whether an empty result is returned or 404 is. Should be consistent though and certainly should be what the caller (software) expects.
|
|
|
|
|
|
I'm with you on this. 404 is an HTTP code. It's a transport condition, not a data condition.
The correct code to return is 204.
204 No Content
The server successfully processed the request and is not returning any content.
List of HTTP status codes - Wikipedia
|
|
|
|
|
Just reading this about bowing and curtsying...
What happens if you don't bow/curtsy? Is there jail time, a fine, hand spanked??
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Traditionally you are going to be deported to Australia.
I have lived with several Zen masters - all of them were cats.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
