What's the correct way to view idempotency in terms of HTTP DELETE?

Question

I have spent a lot of time recently reading the HTTP 1.1 specification and relating it to REST. I have found that there are two interpretations of the HTTP DELETE method in rega

Answer 1

Wikipedia defines Idempotence as an operation that:

can be applied multiple times without changing the result beyond the initial application.

Notice that they talk about the result of the operation. To me, this includes both the server state and the response code.

The HTTP specification is a bit more vague on the matter. It defines it specifies that HTTP methods are Idempotent:

if the intended effect of multiple identical requests is the same as for a single request.

If you interpret effect as result in the Wikipedia definition then they mean the same. In any case, I question the practical benefit of telling clients that the resource as already been deleted.

Final point: Idempotence is defined in terms of a single client. Once you start introducing concurrent requests by other clients, all bets are off. You are supposed to use conditional-update headers (such as If-Match-ETag) to deal with such cases.

To reiterate: you should return the same return code, whether the resource just got deleted, was deleted by a previous request, or never existed at all.