DELETE is supposed to be idempotent.
If I DELETE http://example.com/account/123 it\'s going to delete the account.
If I do it again would I expect a 404, sin
Yes. Regardless of the response code.
From latest RFC for HTTP 1.1 (emphasis mine):
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
It explicitly says that the response might differ. More importantly, it points out the reason of the concept: if an action is idempotent, the client can repeat the action when it encounters any error, and knows that it won't crash anything by doing so; if not, the client will have to make an additional query (possibly GET
) to see whether the previous one is effective, before it safely repeat the action. As long as the server can make such guarantee, the action is idempotent. Quote from another comment:
Computing idempotence is about the robustness of a system. Since things can fail (e.g. network outage), when a failure is detected, how do you recover? The easiest recovery is to just do it again, but that only works if doing it again is idempotent. E.g.
discard(x)
is idempotent, butpop()
is not. It's all about error recovery.
I think the same thing, 404 - Account doesn't exist.
You could argue 400 - Bad Request. But in the sense of REST the object you requested to perform an action on doesn't exist. That translates to 404.