This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Rust Web Development and have Bastian Gruber on-line!
See this thread for details.
Win a copy of Rust Web Development this week in the Other Languages forum!
  • 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:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

What is an Idempotent Requests

 
Ranch Hand
Posts: 280
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is Idempotent Request? Which all methods in Http are Idempotent and why. Please explain me the concepts. Thanks a lot.
[ July 24, 2007: Message edited by: David O'Meara ]
 
Bartender
Posts: 9626
16
Mac OS X Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Have a look at this.
 
Ranch Hand
Posts: 293
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
you can think like if request is not modifying anything in your database(although server-side is more correct word) then it is idempotent.for example if you are firing select query.. definitely get is idempotent if you use it correctly..

post is non-idempotent as its purpose is to modify...
[ July 24, 2007: Message edited by: raj malhotra ]
 
Siddharth Bhargava
Ranch Hand
Posts: 280
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
fine GET method is idempotent and POST is not idempotent but what about the rest of the HTTP methods.... which are idempotent and which are not and why ???
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
GET - idempotent or safe (no side effects on server)
as it requests to return the content on the server and not modify it

POST - not impotent or unsafe (side effects on server)
as it might modify the contents on the server

HEAD - idempotent or safe (no side effects on server)
as it will just ask for header part and not the content in the response (response similar to GET except the body)

PUT - not impotent or unsafe (side effects on server)
ask the server to put or modify data on server at particular uri

DELETE - not impotent or unsafe (side effects on server)
delete the resource on server

OPTIONS - idempotent or safe (no side effects on server)
asks for options available on server like content-length

TRACE - idempotent or safe (no side effects on server)
ask to return traceback of the request

CONNECT - idempotent or safe (no side effects on server)
just ask to connect to the server with host and port args

for more info go to http://www.w3.org/Protocols/
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And it's not really about never making updates, but about making the same update every time. If a PUT sets shoe size to 8 every time you call it, it can still be idempotent. If it increments a counter every time, it isn't.

From W3C Protocols:

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


All this tells how HTTP protocols "should" work. There's nothing but convention to prevent the code we add to an application server from breaking all the rules.

One time we care about this is when working with unreliable messaging. Maybe we send an update and never get a confirmation reply, so we send another copy of the same update. If it's idempotent, the second update will do no harm.
[ August 01, 2007: Message edited by: Stan James ]
 
Siddharth Bhargava
Ranch Hand
Posts: 280
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks everybody got the concept....
 
Rancher
Posts: 43027
76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by sunny dh:
PUT - not impotent or unsafe (side effects on server)
ask the server to put or modify data on server at particular uri

DELETE - not impotent or unsafe (side effects on server)
delete the resource on server


To expand on what Stan said, not only should PUT and DELETE be implemented in an idempotent manner, but being safe and being idempotent are not the same concept.
[ August 12, 2007: Message edited by: Ulf Dittmer ]
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Following was written by sunny :

PUT - not impotent or unsafe (side effects on server)
ask the server to put or modify data on server at particular uri



However, on Pg. 114 of "Head First Servlets and JSP", it is written that GET, PUT, HEAD are idempotent (it must have been misspelled as impotent) according to HTTP spec 1.1.

So I guess except POST (which passes data to the server "to be processed") every other HTTP method is idempotent. However, we can have an non-idempotent implementation of doGet() method in our Servlet but that does not mean that the HTTP GET method is non-idempotent.
 
Sheriff
Posts: 67619
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A properly implemented PUT is idempotent. Setting a value to the same value will end up with the same result each time.

This is because idempotent does not mean "won't change the server", it means "results with the same result each time".
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic