REST DELETE idempotency

Question

Given a DELETE request that will delete resource at an integer index, does the possibility of recreation of a resource at that index break strict idempotency?

e.g. a DELETE request is made to /api/resource/123 deletes the resource at 123. Then a post request is made which creates a new resource which can be retrieved by a GET request to the same url.

It seems to me that for the original DELETE to be properly idempotent, the API should never create a new, different, resource with a previously used id, but I can't find a clear reference.

Answer 1

Given a DELETE request that will delete resource at an integer index, does the possibility of recreation of a resource at that index break strict idempotency?

No.

RFC 7231

A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

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.

Notice: a generic client can retry the request; the client doesn't need to know anything about your particular implementation.

It seems to me that for the original DELETE to be properly idempotent, the API should never create a new, different, resource with a previously used id, but I can't find a clear reference.

That's not at all the case. Think about a static website. Can you, the website owner, delete foobar.html ? Of course you can. Can you recreate it later? Of course. If that's true, then it ought to be true for remoted editing as well.

And if it is true for remote editing of a web site, it should also be true for any other REST API. The point of the uniform interface is that consumers don't need to know if they are talking to a file system, a document store, a database, or some sophisticated service. The job of the API is to act as an integration layer, so that the underlying implementation acts just like the web.

Answer 2

In fact, this has nothing to do with the idempotent behavior of the methods. This is the problem of naming resources. Because If the resource never existed, the deletion will behave exactly as after the resource has been deleted. Yes, a second request will delete the new resource with the same name. But if you are experiencing this problem, simply create a unique resource name.(UUID for example) You can also try using the database index. Even if the entry with the key "123" is deleted - the database does not create it again.