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

GET request to submit data (instead of POST) ?

 
Celinio Fernandes
Ranch Hand
Posts: 549
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have a question relative to the use of POST and GET requests.

POST is not idempotent. It has side effects if you issue a POST request repeatedly.
While GET is idempotent.

So my question is:
why do developers choose the POST request to modify data in a database, for instance, instead of the GET request ?
[ November 28, 2006: Message edited by: Max Fernandes ]
 
Gowher Naik
Ranch Hand
Posts: 643
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According HTTP specification POST is not idempotent and GET is idempotent.
EveryOne is working according HTTP specification.It is upto developer to make GET or post idempotent.Now if you will make GET non-idempotent and POST idempotent then you are doing opposite of what other developers do.
 
Siddharth Purandare
Ranch Hand
Posts: 101
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,

What I think is that secrecy of data is very important while communicating with servlet so if you are sending some valuable information (like SSN number in US context) to database via doGet() method then the data is not considered as secure also if the data is too large then also usage of post is advisable in most of the cases.

Hope this helps.

Cheers!!!
 
Deepak Jain
Ranch Hand
Posts: 637
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes i read the message in alert window. Still i feel this might help in understanding the consequences of using GET to update data on webserver can be fatal.

The RFC allows a user-agent, such as a browser to assume that any idempotent request [GET, HEAD, OPTIONS, PUT, DELETE, TRACE, ] can be retried without
informing the user.
This is done to improve the user experience when connecting to unresponsive or heavily-loaded web servers.

However, note that the idempotence is not assured by the protocol or web server. It is perfectly possible to write a web application in which (e.g.) a database insert or update is triggered by a GET request - this would be a very normal example of what the spec refers to as "a change in server state."

This misuse of GET can combine with the retry behavior above to produce erroneous transactions - and for this reason GET should be avoided for anything transactional - and used, as intended, for document retrieval only.

Suppose your banking application has a feature to ransfer money from one account to other. If this page was designed using GET rather than POST. Consider this: You want to trasnfer 500 to account X and say the server is bit busy , you click the transfer button and sit back , But since the page is designed using GET and since the server is busy the browser can now send any number of identical requests to the server and now since you have designed this page using GET your doGet() would keep transferring 500 to acct X each time it receives a request to do so and the result you will be bankrupt
Hope this clears.
[ January 12, 2008: Message edited by: Deepak Jain ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic