aspose file tools*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes idempotent. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "idempotent." Watch "idempotent." New topic
Author

idempotent.

Deepak Jain
Ranch Hand

Joined: Aug 05, 2006
Posts: 637
HSFS Second Edition.
Q 4: Page 145

Which Http methods are considered NOT Idempotent.
A GET
B POST
C HEAD
D PUT

Answer POST. However PUT is also Not Idempotent.
From doPut() API Doc
This method does not need to be either safe or idempotent. Operations that doPut performs can have side effects for which the user can be
held accountable. When using this method, it may be useful to save a copy of the affected URL in temporary storage.

Hence Put is also not idempotent.
So the answer to this question must be POST and PUT.

Further
GET, HEAD Idempotent and safe.
PUT, DELETE, POST Non Idempotent and not safe

Trace, Options and Connect do not fall in any category as they are out of context for this question.

Is my explaination correct?


SCJP, SCWCD, SCBCD
Lakshmi Narayanan
Ranch Hand

Joined: Apr 29, 2008
Posts: 58
It is how we implement. GET can also sometimes idempotent.
lets say we do like this

doGet(){
doPost()
}

then doGet cannot be idempotent right?

in general or usualy manner HTP DOC and GET are all idempotent
HTP stands for HEAD, TRACE, PUT
DOC stands for DELETE, OPTIONS, CONNECT


Thanks<br />Lakshmi<br />SCJP 1.4 - 90%<br />SCWCD 5 - 89%
Deepak Jain
Ranch Hand

Joined: Aug 05, 2006
Posts: 637

It is how we implement. GET can also sometimes idempotent.
lets say we do like this

doGet(){
doPost()
}

then doGet cannot be idempotent right?

I am aware of that. I am asking wrt Javadoc.

in general or usualy manner HTP DOC and GET are all idempotent
HTP stands for HEAD, TRACE, PUT
DOC stands for DELETE, OPTIONS, CONNECT

I do not agree with above statements. Please refer my post which is directly from HttpServlet documentation.

Someone ?
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

Hi Deepak,

go through this link (see the each method explanation)

Hope This Helps
Deepak Jain
Ranch Hand

Joined: Aug 05, 2006
Posts: 637
the link is javadoc API. I have read this one. According to that i have come up with the question which is not in synch with HSFS book.
Some one please reply regarding this. IS HSFS correct?
Reidar Gjerstad
Greenhorn

Joined: Dec 02, 2008
Posts: 19
Deepak Jain wrote:HSFS Second Edition.
Q 4: Page 145

Which Http methods are considered NOT Idempotent.
A GET
B POST
C HEAD
D PUT

Answer POST. However PUT is also Not Idempotent.
From doPut() API Doc
This method does not need to be either safe or idempotent. Operations that doPut performs can have side effects for which the user can be
held accountable. When using this method, it may be useful to save a copy of the affected URL in temporary storage.

Hence Put is also not idempotent.
So the answer to this question must be POST and PUT.

Further
GET, HEAD Idempotent and safe.
PUT, DELETE, POST Non Idempotent and not safe

Trace, Options and Connect do not fall in any category as they are out of context for this question.

Is my explaination correct?



Dear Sirs

I am just going through the same practice questions:

Which Http methods are considered NOT Idempotent?
A GET
B POST
C HEAD
D PUT

As far as I can see according to the servlet API doc, both POST and PUT are Not Idempotent: "This method does not need to be either safe or idempotent. Operations that doPut performs can have side effects for which the user can be held accountable."

So I believe the answer should be POST and PUT. I believe the HFSJ is wrong when it states that only POST is Not Idempotent.

I appreciate any feedback.

Cheers
Poonam Kohli
Ranch Hand

Joined: Jun 10, 2009
Posts: 53
I agree with Deepak. I had same thing in my mind. However, i did not bring it up on this forum (no idea why).

I would say POST and PUT both are not idempotent.

Either JavaDoc is correct or HFSJ is correct. Both can not be correct here. Both speak different.
Gert-Jan den Besten
Ranch Hand

Joined: May 02, 2008
Posts: 56

IMHO the question is how HTTP1.1 defines the HTTP methods, not how the Java API describes the Servlets' doXXX() methods.


SCJP 5; SCJD; SCWCD 5.
Reidar Gjerstad
Greenhorn

Joined: Dec 02, 2008
Posts: 19
Gert-Jan den Besten wrote:IMHO the question is how HTTP1.1 defines the HTTP methods, not how the Java API describes the Servlets' doXXX() methods.


It appears to me there is an inconsistency between how HTTP 1.1 defines PUT and how the API doc defines it. According to the javadoc (see above) the PUT can have side effects, i. e. is Not Idempotent. However, according to http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html:

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

Appreciate opinions from authorities here at Javaranch.

Cheers
Gert-Jan den Besten
Ranch Hand

Joined: May 02, 2008
Posts: 56

Reidar Gjerstad wrote:
Gert-Jan den Besten wrote:IMHO the question is how HTTP1.1 defines the HTTP methods, not how the Java API describes the Servlets' doXXX() methods.


It appears to me there is an inconsistency between how HTTP 1.1 defines PUT and how the API doc defines it. According to the javadoc (see above) the PUT can have side effects, i. e. is Not Idempotent.

There is no inconsistency. Let's take a look at HFSJ page 116:

GET is idempotent according to the HTTP spec. But there’s nothing to stop you from implementing a non-idempotent doGet() method in your servlet. The client’s GET request is supposed to be idempotent, even if what YOU do with the data causes side-effects. Always keep in mind the difference between the HTTP GET method and your servlet’s doGet() method.

I think that explains it all.....

Reidar Gjerstad
Greenhorn

Joined: Dec 02, 2008
Posts: 19
Gert-Jan den Besten wrote:
Reidar Gjerstad wrote:
Gert-Jan den Besten wrote:IMHO the question is how HTTP1.1 defines the HTTP methods, not how the Java API describes the Servlets' doXXX() methods.


It appears to me there is an inconsistency between how HTTP 1.1 defines PUT and how the API doc defines it. According to the javadoc (see above) the PUT can have side effects, i. e. is Not Idempotent.

There is no inconsistency. Let's take a look at HFSJ page 116:

GET is idempotent according to the HTTP spec. But there’s nothing to stop you from implementing a non-idempotent doGet() method in your servlet. The client’s GET request is supposed to be idempotent, even if what YOU do with the data causes side-effects. Always keep in mind the difference between the HTTP GET method and your servlet’s doGet() method.

I think that explains it all.....



Hi Gert

I don't see how this explains it all. We were discussing PUT method which can have side effects according to javadoc. If PUT is used to put a file on the server, how could it not have side effects? It's in the nature of the function of the method.

I understand that GET can be written (in poor way) to have side effects. But PUT does have side effect if the basic idea is to upload something to the server.

Cheers
Gert-Jan den Besten
Ranch Hand

Joined: May 02, 2008
Posts: 56

From the Servlet specs (as we are instructed to download by HFSJ):

"This method does not need to be either safe or idempotent. Operations that doPut performs can have side effects for which the user can be held accountable. When using this method, it may be useful to save a copy of the affected URL in temporary storage."

IMO this is exactly the same as the difference between the HTTP GET method and the doGet() from the servlet API. The point is that you can mess up the 'idempotency' of an actual HTTP PUT request by providing a lousy implementation of doPut().

Reidar Gjerstad wrote:PUT does have side effect if the basic idea is to upload something to the server.

Since that's the basic idea, it's not a side effect
That's what an HTTP PUT method is supposed to do.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: idempotent.