Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why are 'PUT' and 'DELETE' considered idempotent?

 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

Both PUT and DELETE change something on the server, so calling them repeatedly does not cause the same effect. So, why are they considered idempotent?

Thanks
Rohit
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Source? Context?
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I got this from: http://esnault.frederic.free.fr/certification/scwcd_notes.pdf


PUT-Sends to the server data to store at specified URI. Server does not process the data ; it only stores them : Obviously there is some change on server
DELETE-Delete specified resource : Again, change on server side
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's obviously not what i was asking for.
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are asking for a sample code, then no, I don't have it. I didn't try using PUT or DELETE http methods. But the method definition itself clearly makes it non-idempotent (if I understand the meaning of idempotent correctly). In the exam , I would choose POST as the only non-idempotent method because HFSJ says so but I was wondering why not PUT and DELETE?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, let's try it this way.

"Why is a car considered an aircraft?"

Do you really think I want an explanation of what a car is?
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
WOW!...Never mind...you take it easy now..Thanks anyway!
I can live and pass the exam without knowing the answer to this.

Thanks
Rohit
 
Paul Clapham
Sheriff
Posts: 21581
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To put it a different way, this is a false statement:
rohit sen wrote:Both PUT and DELETE change something on the server, so calling them repeatedly does not cause the same effect.
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So putting a resource or deleting a resource doesn't qualify as a change on the server?

 
Paul Clapham
Sheriff
Posts: 21581
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I missed out the last part of your quote. Sure, they cause a change on the server. But that's not the definition of "idempotent".
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In other words "why do you think that they are considered idempotent"? Who said so?

In your post you make an assertion that you are questioning without backing it up with a source.
 
Alex Serna
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe this will help you. I wrote down from HFSJ that an idempotent method is one that used in several requests doesn't change the server's state in a negative way. If you do the same PUT or DELETE operation twice you would be placing or deleting the same resource twice which you can't consider a negative effect. Posting the same form buying a book would provably have a negative effect in the application and in your back account.
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well,there are more than one assertions in my post your post just said " Source? Context? " and I thought you were asking me the source of my definitions of PUT and DELETE .

Bear Bibeault wrote:In other words "why do you think that they are considered idempotent"? Who said so?


I don't think they should be considered idempotent but the book says they are idempotent. That was my question. This is my source -

Head First Servlets and JSP : pg 145 , Answer to q4 says that only POST is non-idempotent.




 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's what I was looking for you to post. Without the source of the information, it's hard to know the context for your question.
 
Paul Clapham
Sheriff
Posts: 21581
33
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Negative way" and "positive way" have nothing to do with the definition of idempotent.

Here's an example from mathematics: multiplying a number by 1 is an idempotent operation. That's because applying the operation twice results in the same answer as applying it only once.

Note that the change made, or whether there was a change made, or the nature of any change made, none of those have anything to do with whether an operation is idempotent. The only thing to consider is whether applying the operation twice produces the same result as applying it once.

Now apply that rule to PUT and DELETE.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the horse's mouth (HTTP Spec):
9.1.2 Idempotent Methods

Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

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.

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

Doe that clear it up?
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually no, it doesn't.

In the first PUT request, a resource is added on the server. If I call PUT again, may be nothing happens I am not sure but the effect of first and second request is not the same. After the first request, all other request may have the same effect because the resource is already there.Same with DELETE. May be I am reading too much into it but the effect of PUT and DELETE is different from HEAD, TRACE, OPTIONS or GET which are 100% idempotent. Beause HEAD, TRACE etc dont change anything on first request or any number of requests.

Basically what I am trying to say is the 'state' of the server does change with PUT and DELETE when they are called first time. So why are they idempotent?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 65340
97
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are reading too much into "server state".

The definition of idempotent is "same results" not "same state".

If a do a PUT with certain params, at the end of the op, an item with those params exists on the server. If I do the exact same PUT, the result is the same: an item with those params exists on the server.

Therefore the PUT is idempotent. The fact the first PUT changed server state is moot. The fact that the two PUTS result in the same state is what makes it idempotent.

Something that doesn't ever change server state is, by definition, idempotent because there never a chance that the result will be different, because there aren't any results. But that's just one way of being idempotent.
 
rohit sen
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok..I got it now..Thank You!
 
Nenad Bulatovic
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From the book that OP was reading (Head First Servlets and JSP™, 2ed):

Note: there are several different uses of the word
“idempotent”; we’re using it in the HTTP/servlet way
to mean that the same request can be made twice with
no negative consequences on the server. We do *not*
use “idempotent” to mean that the same request always
returns the same response, and we do NOT mean that a
request has NO side effects.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic