Error Response: Use status code 404 for "resource not found"
Closed this issue · 20 comments
The "error response" section currently states:
HTTP 400: not_found - The post with the requested URL was not found
Both RFC 1945 (HTTP/1.0) and RFC 2068 (HTTP/1.1) define status code 404 for the resource-not-found error case. Please use this.
My concern with returning HTTP 404 is that it implies that the Micropub endpoint itself is not found.
It will still return the JSON response, which should be enough for the clients to see that it's not a simple webserver-default-404-message.
Also, the micropub endpoint will most likely support configuration requests, which also do not 404.
Also, the 404 is only used when editing posts. Creating will work fine, which will make the client consider that the endpoint actually exists.
Sounds to me like a 404 makes sense here
Are there existing examples of similar (RPC-style rather than resource-based) APIs that have this behavior? If it's typical of these kinds of APIs then I'm happy to change it to match.
W3C specifications should not be in contradiction with the IETF RFCs for http without very good reasons.
@akuckartz that doesn't answer my question. "Resource not found" meaning the Micropub endpoint, or the object being referred to in the RPC request?
@akuckartz RFC 2068 says about 404: "The server has not found anything matching the Request-URI." In the case of Micropub, the request URI is the Micropub endpoint itself, rather than the object being referred to in the request. This is why it seems inappropriate to use 404 as the response here. One might even go so far as to say RFC 2068 explicitly forbids using 404 as the response in this case.
404 is the response to a request for a URI, not for any operation done as a result of a request to a URI
404 would make sense if micropub had been designed to work with PUT,DELETE,UPDATE verbs performed against the location of the post, but it was not.
400 continues, IMO, to be the least smelly of the options
Right, because the URL is not part of the request uri but rather the request body – then I agree that 400 is the correct one
I understand the reasoning to see micropub as a RPC-style API, and understand that in this case 404 would indicate that the RPC endpoint does not exist at all.
Looking at some common existing RPC-over-HTTP specifications (XML-RPC, SOAP and JSON-RPC) told me that neither of them makes use of different HTTP status codes (except in the case of underlying errors). They always use HTTP/1.x 200 OK as response status code and signal their error within the resonse body.
Also, we should reference the most recent HTTP documentation on status codes:
Also, 404 is cachable unless you add headers to explicitly not do that: https://tools.ietf.org/html/rfc7234#section-4.2.2
After quite a bit of discussion during the f2f meeting, we came to the following conclusion:
- drop "not_found" from the list of error codes because that case was already covered by "invalid_request"
- add a sentence saying how to handle unexpected error codes
- add a header to the bullet list of error codes to indicate this is the list of error strings defined by the spec
@cweiske how's this? https://micropub.net/draft/#error-response
I'd say all errors are covered by invalid_request. This is ridiculous.
That's actually the idea basically. All errors other than permissions errors are "invalid request".
I counted permission errors into "all". If you may not access a resource, then your request is invalid. If you don't have enough scope, your request is invalid.
So the only error code left is "YOU DID SOMETHING WRONG". The error code can be fully dropped now.
There are actual user-facing reasons for returning a different error when there is a permissions error. Returning "forbidden" tells the client the access token is wrong and the user should log in again. Returning "invalid scope" tells the client the access token is fine but the user needs to re-authorize again to include additional scope, or the client can't do that operation.
I don't want to continue discussing this issue.
httpclient delete method showing like this can anybody help me ????
DELETE http://localhost:3000/customers/1 404 (Not Found)
ERROR HttpErrorResponse {headers: HttpHeaders, status: 404, statusText: "Not Found", url: "http://localhost:3000/customers/1", ok: false, …}