If you call GET method on server nothing will be changed on server, but if you call POST then server will be changed may be a some additional data will be added in to the server, so GET is idempotent while POST is not.
Originally posted by Hanuma Deepak Muvvala: If you call GET method on server nothing will be changed on server, but if you call POST then server will be changed may be a some additional data will be added in to the server, so GET is idempotent while POST is not.
It's important to note that that is how it should be. It is of course perfectly possible to design web applications that do make changes as part of a GET; these violate the HTTP specification. To quote what Aristotle Pagaltzis said on the rest-discuss mailing list:
The server can do anything it wants to handle a GET request, involving any side effects whatsoever. However, there is a clear understanding that a GET request from a client can never be construed as a demand for any of these side effects. The client bears no blame for issuing a GET request that caused the server to do something untoward; if something undesirable happened, it�s the server�s fault.
I know that in get method data gets visible on the query string and in post it sendon the server through socket whic is invisible on the querystring...........
I hope about get and post i said as above is correct...
So i dont understand what ruquia said; The Get is idempotent means the same operation applied multiple times yields the same result...where as with a post it has side effects that results in varied outputs.
same operation applied multiple times yields the same result means in which manner..please explain this.
Originally posted by Brijesh shah: same operation applied multiple times yields the same result means in which manner..
Imagine an operation that retrieves a particular database record for display. The URL might be something like ".../showOrder?orderID=123456" and is implemented with a GET. Idempotency means that accessing the URL one time or multiple times yields the same result. Clearly it does in this case - accessing this URL gives you the same result every time you access it. It retrieves the web page that shows the record. You can hit reload in the browser as many times as you want - the result is always going to be exactly the same page.
Now, POST is generally used to change something, e.g. inserting a new record into a database. If you have just submitted a form that adds a new order record to the database, and if you then hit Reload (in other words, you access the same URL again), you'd be inserting another record. That means the result would not be the same. That's why browsers generally ask the user before reloading a page that was the result of a POST - because POSTs often change something, and doing the same change twice is usually not what the user wants. (As an aside, that's also the reason of existence for the PostRedirectGet technique. It allows you to submit something with POST, and then show a page that can be reloaded without problems.) [ November 23, 2007: Message edited by: Ulf Dittmer ]
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop