What are examples of non-idempotent HTTP sequences of idempotent HTTP methods? I've been thinking of possible examples as well as trying to find ones on the Internet but I simple don't really understand what "non-idempotent sequence" means - although I do understand what an idempotent (single) method is.
Let us take a look at https://www.rfc-editor.org/rfc/rfc2616.pdf
However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.
What exactly does "result" mean here? I've read that PUT -> GET sequence (The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference, 1349) on the same resource is non-idempotent because the result of the second request depends on the result of the first one. But let us analyze it:
PUT("mysite.com", "Hello world");
GET("mysite.com", "Hello world");
The state of the site after this operations will be that it will contain the "Hello World" text. OK, so now we are after the first execution of our sequence. Now we do:
PUT("mysite.com", "Hello world");
The state of the site doesn't change. If the result of a method should be interpreted as the state of the site after this method is applied on a given resource, then the result is clearly the same as it was after the first execution of the entire sequence. However it's also possible that it should be understood that the result of applying PUT method is that contents of the site after this method is applied and the result of GET method is the response received by a user. If that is the case, the result of the last operation is not the same as the result of the initial sequence, simply because PUT and GET methods do different things. But this interpretation lead to further complications as I will show later in this post. For now, let us go on:
GET("mysite.com", "Hello world");
The result of that operation is clearly the same as the result of the execution of the initial sequence.
Now, I'll explain what complications of the interpretation I gave above are (or would be): it'd simply basically mean that practically any sequence of GET methods wouldn't be idempotent (unless every GET asked for the same resource). Indeed, the result of GET("mysite.com", "img1.jpg") will be always different than GET("mysite.com", "img2.jpg"). It'd effectively make pipelining GET requests impossible (RFC2616 states clearly that "Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods").
However, the fact that idempotent methods are used within the context of pipelining allowed me to do some educated guesses about its intended meaning. Namely: I suppose that it was primarily defined in order to prevent HTTP servers from processing requests in parallel if the reponse to the n-th response could depend on the effect(s) of one (or many) of previous reqests (RFC2616 allows processing requests in parallel although it states that responses to the received requests must be sent in the order in which these requests were received). But if this is the case, then the original definition's simply wrong and it should be stated in the manner similar to that:
"Let us assume that we have a sequence a_n of HTTP methods numbered from 1 to n. Let us say that for any i in {1, 2, .., n} method number i returns result R_i. Let us construct a sequence w_p by adhering to the following rules:
1) p is any arbitrary taken non-negative natural number,
2) for each p w_p belongs to {a_1, a_2, ..., a_n}.
If for every w_p the condition:
if w_p = a_j, then the result of w_p is R_j
holds, then we say that the sequence a_n is idempotent".
However what I presented are just my suppositions.
Can you tell me if they are right or wrong?