Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Regarding Idempotent Request  RSS feed

 
Sri Vidya
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what is meant by idempotent request and non idempotent request?
what is it that POST is not idempotent and GET is idempotent?
[ July 03, 2008: Message edited by: Bear Bibeault ]
 
Siddharth Naik
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Official definition from dictionary.com is "unchanged when multiplied by itself". In HTTP perspective, you can send idempotent requests multiple times without altering system state / data / resource.

Since get requests are meant to get required resource and not change anything, it's considered idempotent. Although technically it's feasible to implement your program in bad way that would alter the data even for get request.

Post request are usually implemented to achieve server side action that would alter data. For example, providing your credit card and submitting purchase button. If you submit the button twice, chances are that you might pay twice! Since post requests are non-idempotent, one should take extra care in implementing it such that duplicate request doesn't go through.
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In practice, generalizations such as "GET" is idempotent and POST is not idempotent are not true.

Something is idempotent when you can do it multiple times and have the same result. So if you do a command "delete file foo.baz" then if you do it once, foo.baz is gone. If you do it twice, foo.baz is gone. But to be properly idempotent, the response to get command has to be "foo.baz is gone" and not just that the first time, and "there was no foo.baz to delete" the second

If you GET a static page, say index.html, then its idempotent.
If your GET returns a secret nonce, then it is not.
 
Amit Ghorpade
Bartender
Posts: 2856
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In practice, generalizations such as "GET" is idempotent and POST is not idempotent are not true.

Its true, whether a request is idempotent or not is implementation dependent.
But usually is assumed that GET is idempotent and POST is not.


Hope this helps .
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amit Ghorpade:Its true, whether a request is idempotent or not is implementation dependent.
But usually is assumed that GET is idempotent and POST is not.


I'm missing the point of your posting. It is not safe to assume that GET is idempotent, I showed you why. When folks are discussing idempotency, its not because they want to talk about weather or politics.

it is very bad to assume that GET is idempotent.

Do a GET on http://news.google.com/
and see if it is idempotent over time.
 
Sri Vidya
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot to all of you
 
Sri Vidya
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot to all of you
 
Amit Ghorpade
Bartender
Posts: 2856
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Pat Farrell
I'm missing the point of your posting. It is not safe to assume that GET is idempotent, I showed you why. When folks are discussing idempotency, its not because they want to talk about weather or politics.

it is very bad to assume that GET is idempotent.


I already mentioned in my above post that idempotency is implementation dependent.

For your reference please see the HTTP official documentation
The specification itself says that GET can be considered idempotent.
This should make my point clear.


Hope this helps
[ July 04, 2008: Message edited by: Amit Ghorpade ]
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amit Ghorpade:
I already mentioned in my above post that idempotency is implementation dependent.

The specification itself says that GET can be considered idempotent.
This should make my point clear.


Sorry, no. The spec does not say that. And as you say "idempotency is implementation dependent." which means that assuming that a GET is idempotent is not a reasonable assumption. The implementation may or may not be idempotent.

If the point of answering is to allow implementions that are correct, your answer is not helpful, as it is not correct, and you seem to want to argue.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65824
134
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amit Ghorpade:
For your reference please see the HTTP official documentation
The specification itself says that GET can be considered idempotent.
This should make my point clear.

The Specification says no such thing. In fact what it does say is:
These methods ought to be considered "safe".

which is very different from what you stated.

"ought to be" and "can be" are completely different in meaning.

GETs should be coded to be idempotent, but nothing forces them to be so.
[ July 04, 2008: Message edited by: Bear Bibeault ]
 
Paul Clapham
Sheriff
Posts: 22185
38
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Amit Ghorpade:
For your reference please see the HTTP official documentation
The specification itself says that GET can be considered idempotent.
This should make my point clear.
No, it doesn't make your point clear. On the contrary. It says
Methods can also have the property of "idempotence".... The methods GET, HEAD, PUT and DELETE share this property.
So maybe it's just an English language thing, but to me that just says that a particular instance of the GET method can be idempotent. It doesn't say that GET can be "considered" idempotent. To me "considering" it to be idempotent would be the same as assuming it was idempotent. Which it clearly isn't.

The spec does say that GET ought to be considered "safe". Which isn't the same as idempotent. Note also that it uses the words SHOULD and "ought to be" in that section, not MUST and "is", so in practice we can't assume that an instance of GET is safe, either.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Paul C]: So maybe it's just an English language thing, but to me that just says that a particular instance of the GET method can be idempotent.

To me, it's saying clearly that GET is idempotent. "The methods GET, HEAD, PUT and DELETE share this property." Not "can share" or "may share". Simply "share". What property do they share? The prededing sentence refers to the property of idempotence. That's the only property this sentence can be referring to. Yes, that preceding sentence also uses the word "can", but that's not part of the property itself. According to the spec here, methods in general can have the property of idempotence, and the methods GET, HEAD, PUT and DELETE do have this property.

Now I'm just saying, that's what I think the spec says. I can see where Amit is coming from - I read it the same way. On the other hand, I don't think the spec is correct here. It should have said that these methods are expected or even required to be idempotent, but at the same time, we have to assume that they may not be.

[Pat Farrell]: Do a GET on http://news.google.com/ and see if it is idempotent over time.

I believe this misses the point of idempoency as applied to HTTP requests. The spec defines idempotency in terms of side effects, of which GET should have none. For an even simpler example than news.google.com - consider GET requests to a time server. Yes, each request will generally see a different time as the response. But those requests don't affect the time as reported by the server. In that sense, the requests are idempotent. The responses may be different, but the final response is determined only by the time of the final request. Preceding requests had no effect.

Now here I'm relying on my own interpretation of what "side-effects" means, and this term does not appear to be well-defined by the HTTP spec. So this point is much more ambiguous than my first point above (that GET is idempotent, according to the spec). Nonetheless, I believe it's quite consistent with the first point. How could GET ever be idempotent for any time-sensitive web site (which is to say, almost any web site in existence anywhere) - unless the definition of idempotence excludes the exact text of the response, and instead considers only whether the request has significantly altered the state of data on the server?

As another example, what about sites with hit counters? I would argue that since each GET does alter the data that would be seen by other GETs, such sites are not idempotent with respect to the hit count. But they may still be (and in general, damn well should be) idempotent with respect to all other data they manage. Thus, I would argue that it's not really useful to define idempotency as a purely binary global quantity. It's scoped and context-dependent. A server can be idempotent in some respects, but not in others. Generally it's important to be idempotent about the things that people actually care about and expect not to change without good reason (like how much money has been paid, or how many items are in inventory) - and not about other things, which are expected to change anyway (like hit count).

[Paul C]: The spec does say that GET ought to be considered "safe". Which isn't the same as idempotent.

Looks to me like the spec defines "safe" as not having side effects (other than retrieval of current data). And it does state "A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources)." Which seems to mean that all safe methods are also idempotent. While other methods like PUT and DELETE are not safe, in that they do modify the state of the server, but they are (usually) idempotent, in that performing them more than once in a row has no side effects (does not alter the server state). Well, maybe the first one gives a response "post deleted" while the second gives the response "can't delete post (does not exist)" or something similar. But I'm not convinced that matters - the second DELETE did not have any side effects.

I'm aware that idempotency has a mathematical definition which is more strict than this. But I think that a looser definition (ignoring changes in response text and concentrating only on changes in data on the server) is more appropriate to web development. A really strict definition of idempotency would exclude so many sites that it would be pointless to talk about idempotency at all. But I think there's a useful concept here that web developers should think about - what happens if a user saves a link and then executes the same request again later? The way the HTTP spec talks about idempotency is a bit vague and even, well, wrong sometimes - but I believe it's possible for us to recognize what they meant, or what they should have said. And yet, from this thread I see that others have read the same words and seem to have very different interpretations. Still, I would suggest that when a poster points to the spec

Still, it seems obvious to me where Amit got the idea that GET is idempotent - it's right there in the spec. And he noted that in reality it depends on the implementation, not the spec. So the spec is wrong in this case. Let's put the criticism where it's deserved - on the poorly-worded spec. Not on Amit.
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, the spec is a bit fuzzy, and talks about "can be" idempotent.

Look outside that spec, and look at the regular meaning of the term. For example:
http://en.wikipedia.org/wiki/Idempotent
"A unary operation (or function) is called idempotent if, whenever it is applied twice to any value, it gives the same result as if it were applied once. For example, the absolute value function is idempotent as a function from the set of real numbers to the set of real numbers: abs(abs x) = abs(x)."

Very few things about HTML are always idempotent. Many can be or may be.

In the general meaning of the term, doing a GET twice needs to result in the same response.

A possible 'side effect' of the get could be to increment a "counter" that shows how many times the page was looked at. Each GET will increment the counter, this is the side effect.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm pretty sure I addressed all those points in my past post. E.g. "I'm aware that idempotency has a mathematical definition which is more strict than this." And as I said, a site might well be non-idempotent with respect to its hit counter (I would argue that all hit counters are inherently non-idempotent) but idempotent with respect to most everything else. Frankly, if your definition of idempotence excludes Google news or a simple time server, I don't think it's a very useful definition for web programming. Any time a sites response changes over time, but not as a direct consequence of previous posts (a "side effect") - that is not a violation of idempotence, as far as I'm concerned. Yes, it is a violation of idempotence using the more strict definition of idempotence found in mathematics and elsewhere, but it's not a violation of the (admittedly vague) definition of idempotence given in the HTTP spec (as I interpret it, in order for that definition to be useful to web programmers). I realize that's not the only interpretation, but I have explained my reasoning, and why I think the spec's looser definition is still useful - more useful than a stricter definition in this case.

Note that "looser" is not the same as "vague". I'm happy that the spec's definition is looser than the mathematical definition (it's less restrictive), but not happy that it's vague and misleading (what exactly constitutes a "side effect", and is it that a GET is idempotent, or that it should be?). So I'm defending the spec's intent (as I see it) while agreeing that the wording is, ummmm, not optimal.
[ July 04, 2008: Message edited by: Mike Simmons ]
 
Amit Ghorpade
Bartender
Posts: 2856
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Originally posted by Pat Farrell
your answer is not helpful, as it is not correct, and you seem to want to argue.

no I dont want to argue , I just posted my view, which might be wrong, if you think so.

About Bear and Paul, I understand that you people are far superior to me in terms of knowledge and experience, and maybe my view is wrong or I failed to put it in proper words.


Originally posted by Mike Simmons
Still, it seems obvious to me where Amit got the idea that GET is idempotent - it's right there in the spec. And he noted that in reality it depends on the implementation, not the spec. So the spec is wrong in this case. Let's put the criticism where it's deserved - on the poorly-worded spec. Not on Amit.

Thanks Mike for understanding my perspective.


Thank you all
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mike Simmons:
it's not a violation of the (admittedly vague) definition of idempotence given in the HTTP spec (as I interpret it, in order for that definition to be useful to web programmers).

So I'm defending the spec's intent (as I see it) while agreeing that the wording is, ummmm, not optimal.


But you can't tell the spec's intent because the wording is so poor. Its so poor that it offers zero guidance to folks trying to use it.

In this case, I argue that its worse than fuzzy. They are using a well defined term, one that is not used in normal conversation, but using it in a fuzzy way. This is bad, its far worse than "not optimal"

The fact of implementation is that you can not assume that any web page GET is idempotent. It may be, or it may not. So the assumption is unsafe.

If you wrote the servlet that provides the answer, or a buddy did, you could have a separate "contract" that covers whether or not the GET is idempotent. But the spec provides nothing here. So you would have to publish your "contract" before anyone not your buddy could use it.

There is no equivalent to the US Supreme Court, who can issue rulings about the "original intent" or at least a modern interpretation of the rule. And given the near world-wide use of the 'net, and the many 'non conformatant' implementations, there is no practical way to have the spec be improved.

So the only safe assumption that developers can use is that its not idempotent.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Pat]: So the only safe assumption that developers can use is that its not idempotent.

I think you meant, not necessarily idempotent. I see no reason to assume that sites are necessarily not idempotent, but I agree that we really have no way to be sure either way, and no practical enforcement of the spec.

On the other hand, for sites we do have control over, I think it makes perfect sense to make GET idempotent in the usual sense - it should have no significant side effects. PUT and DELETE too, in the unlikely case that you use them. It's up to the webmaster to decode what's "significant" here. So the spec is not really useful as a specification, but it's still useful as advice.
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't see any difference between "not idempotent" and "not necessarily idempotent" when you are talking about "assumptions"

As you say, when you control it, you can have a separate contract and make it be idempotent. But that is an explicit agreement, not an assumption.
 
Amit Ghorpade
Bartender
Posts: 2856
10
Fedora Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following line is taken directly from the specification

the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

Now let me put it in a different way,
there's no doubt that the above statement is unambiguous.
And it says that TRACE is inherently idempotent but in practice, it is possible that the trace returns different intermediate addresses almost every time. So is it not idempotent?

So the end user will always think that GET is not causing any side effects on the server, besides only information retrieval. But if he ends up with something entirely different, the implementer should be at fault for changing the semantics of the request.


Hope this helps .
 
Pat Farrell
Rancher
Posts: 4678
7
Linux Mac OS X VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mike Simmons:
[Pat]: So the only safe assumption that developers can use is that its not idempotent.

I think you meant, not necessarily idempotent.


No, very clearly, it is not safe to assume GET is idempotent.
The reverse is: assume GET is not idempotent.

Your "necessarily" word adds nothing to the topic.
Its a waffle word.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Pat]: I don't see any difference between "not idempotent" and "not necessarily idempotent" when you are talking about "assumptions"

Apparently not. And I do. When I lock my car, I do it because other people may be thieves. I don't say that they are thieves.

But, whatever. I didn't respond earlier because we've both already made our points, and further nit-picking over the wording doesn't seem terribly important. You seem to still want to keep it going though. Enjoy.
[ July 07, 2008: Message edited by: Mike Simmons ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!