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 Unavaila

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.