1

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?

Community
  • 1
  • 1
Flogex
  • 584
  • 6
  • 15

2 Answers2

2

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.

jwismar
  • 12,164
  • 3
  • 32
  • 44
  • Then a single DELETE had to be considered not idempotent, too. I was wondering because throughout the rest of the book they use the term correctly. – Flogex Feb 06 '19 at 19:38
  • Good point. Although some folks use a 200 on a DELETE even if not found, for exactly this reason. – jwismar Feb 06 '19 at 20:07
0

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".

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • As far as I understand it, idempotency refers to the resource state. See for example [this SO answer](https://stackoverflow.com/a/4088451/8336143). But yeah, I shouldn't cling to the exact definitions. – Flogex Feb 06 '19 at 19:43
  • Yes, but in this case, no matter how many times you retry these operations, the resource will still be deleted, no matter whether the client has read the response. – CodeCaster Feb 07 '19 at 08:15