CODEWITHSUNDEEP
resthttp
Flogex
Flogex

Reputation: 674

Why is GET + DELETE not idempotent?

I am reading RESTful Web APIs by Leonard Richardson and Mike Amundsen. In chapter 11 they write about Pipelining in HTTP/1.1 (page 247):

A client may pipeline any series of idempotent HTTP requests, so long as the series as a whole is also idempotent. […]

I’m going to send two requests over a pipeline. First I’ll retrieve a representation of a resource, and then I’ll delete the resource:

GET /resource

DELETE /resource

GET and DELETE are idempotent, but their combination is not. If there’s a network problem after I send these requests, and I don’t get the first response out of the pipeline, I won’t be able to send the requests again and get the same result. The resource won’t be there anymore.

In my understanding, idempotency means that after sending a request several times the resource state is the same as after sending the request only once. In this particular case, the resource state stays the same, since the resource is still deleted after a second request.

Why do the authors refer to this request combination as not idempotent?

Upvotes: 1

Views: 182

Answers (2)

CodeCaster
CodeCaster

Reputation: 151674

The terms "idempotent" and "safe" apply to single requests. The authors here decided it applies to multiple requests as well.

In order to understand what they mean, you'll have to get their intentions. Pipelining of requests is done in order to decrease latency. So the developer of the client application prepares and successively fires a GET and DELETE over the same connection without awaiting the first response.

They do this under the assumption that the response to the GET will be successfully received, after which the DELETE can be safely executed. Assume the client application has to read the GET response and, for example, store it locally, after which the server version can be discarded.

Now if for whatever reason the connection is lost before the client can read the response to the GET request, the resource at the server will still be deleted - and the client won't be able to obtain the resource by retrying the requests. So in that sense, this combination of requests isn't considered "idempotent".

Upvotes: 0

jwismar
jwismar

Reputation: 12268

You're right that the system state will be the same, but it sounds like they're using the term to point out that the client's view will not be the same. (I.e. the second time around the response on the GET will be 404 instead of 200.) I think that your interpretation of "idempotent" is better, but I can also understand the point they're trying to make.

Upvotes: 2

Related Questions