• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

idempotent.

 
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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 ?
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Deepak,

go through this link (see the each method explanation)

Hope This Helps
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 56
Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMHO the question is how HTTP1.1 defines the HTTP methods, not how the Java API describes the Servlets' doXXX() methods.
 
Reidar Gjerstad
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 56
Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 56
Python Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic