My apologies if I am repeating what others have said, but just yesterday I chose to give a 404 for an operation that could not be concluded because a resource is not available. A 404 is not about pages but about resources. It is perfectly legitimate that a resource is not available anymore or is temporarily down in a non internal error kind of way.
A REST request on a IoT device can return 404 if the device is not available at the moment. Any redirect is meaningless and actually breaks the semantics of 404. My understanding is that 404 has been so connected with the file like persistent resources, that people forgot the elegance of the wording in the standard.
I can understand the popular usage change, but I think then the standard actually becomes incomplete because it only fits web pages or document type resources when an HTTP status code is about Hyper text Transfer Protocol.
Alternate view disagreeing with what postulated above is that, actually HTTP has been abused and is being used in scenarios that have nothing to do with Hyper Text, looking at you JSON REST :D
I don't think 404 is the right code for "resource not available". If you want to send a request to a device, and it's not online, that is "503 Service Unavailable". The device exists, after all, it just isn't available to handle the request.
Ultimately, HTTP has a very weak set of status codes for application layer concerns. The vast majority of the ones that sound good mean something about the HTTP layer rather than the application layer -- for example, it makes sense to return "precondition failed" if you request deletion of a directory that isn't empty (the precondition for deleting directories is that they are empty), but "412 Precondition Failed" means that the client supplied an HTTP precondition like "If-Match: abc123" and it failed. Trap for the unwary.
For this reason, I think REST largely fails to provide what API authors and users desire. If your API server can successfully convey an error to the client, you might as well say '200 OK {"error": "The Raspberry Pi you were looking for exists, but it's turned off or someone used its Ethernet cable to test their scissors and the test went very well."}' Now the client actually knows what's going on.
The Ethernet cable scissor test success made me laugh :D.
We agree on the general weak suitability of http codes to convey application layer status, but I kind of disagree on the 503 because it implies an overload and an internal error, which is not the case. Also I really believe the resource not a available is as accurate as it gets.
In the end I agree with you we may be splitting hairs with a very unsuitable status report and should just send 200 with the error. I have done this before actually, but it tickles my neck a lot to see an OK, then error.
A REST request on a IoT device can return 404 if the device is not available at the moment. Any redirect is meaningless and actually breaks the semantics of 404. My understanding is that 404 has been so connected with the file like persistent resources, that people forgot the elegance of the wording in the standard.
I can understand the popular usage change, but I think then the standard actually becomes incomplete because it only fits web pages or document type resources when an HTTP status code is about Hyper text Transfer Protocol.
Alternate view disagreeing with what postulated above is that, actually HTTP has been abused and is being used in scenarios that have nothing to do with Hyper Text, looking at you JSON REST :D