• 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

Doubt in Get and Post

 
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I know that GET doGet() is Idempotent and POST doPost() is non Idempotent.

My understanding is like this a developer can still go ahead and write non idempotent GET doGet() and a Idempotent POST doPost(). But actual problem will come up when the code is being executed like given a scenario
where; Load on the Server is to high the browser will go ahead and submit multiple requests without even informing user until servers responds to it since in Servlet Spec we have GET doGet() is Idempotent. in this case if the Developer has writen the code by making update or insert statements in GET rather than fetching or Querying the data it will create lot
of problems because we have implemented the methodes against the Servlet Spec.

Because of this reasons the developer should take care to put only the Querying logics in GET doGet()and Updating logics in the POST doPost() and thus following the Servlet Spec.

Is My understanding correct

Thanks
 
raja ram
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Any Updates on this.

Thanks
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, your understanding is correct that querying should be in the GET requests, and updating in POST requests, and it is the developer's responsibility to make sure it's done this way.

However, even if the updating is in a POST request, if the user gets impatient waiting for a response, and hits "Submit" several times, you could still have a problem. The server doesn't automatically do anything special to handle multiple POST requests. For all the server knows, the requests may be perfectly valid. So it is still up to you, the programmer, to make sure that your application will deal with that situation.

The real reason to have updating only in POST requests is that client browsers typically handle GET and POST requests differently. If you you hit "Reload" on a page or navigate to it through the history stack and that page is a GET request, the browser will just go ahead and submit it. If it does any updating, you could be in trouble! But if that page is a POST request, the browser should inform you that you are about to send a POST, and give you a chance to cancel it.
 
raja ram
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Thanks for the reply

However, even if the updating is in a POST request, if the user gets impatient waiting for a response, and hits "Submit" several times, you could still have a problem. The server doesn't automatically do anything special to handle multiple POST requests. For all the server knows, the requests may be perfectly valid. So it is still up to you, the programmer, to make sure that your application will deal with that situation.



in this case how can we prevent the duplicate request is there any way for this.

Thanks
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The form might have a hidden field that contains some predetermined ID that is only good for a single request. So if the server sees a 2nd request with the same ID, it can reject it as a reload or resubmit.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic