Hi can any one please tel me why JSP Gives us Two Implementation for Service method ,Beside the difference of size of Submission of data n Security Why JSP gives us two Methods get n Post One Could have served the Purpose ?
And note that this wasn't as decision made by the designers of JSP or Servlets. This is defined in the HTTP protocol, which is how the web works - any web programming language will support it in some way. There are more than two, although GET and POST are the most common - see Seetharaman's link for the complete list.
Correct me if I'm wrong, but JSPs don't have two service methods, just one that's automatically generated. The JSP contents apart from declarations go in this method automatically. Servlets have 7 methods for servicing requests, including doGet and doPost.
Rob Spoor wrote:Correct me if I'm wrong, but JSPs don't have two service methods, just one that's automatically generated. The JSP contents apart from declarations go in this method automatically. Servlets have 7 methods for servicing requests, including doGet and doPost.
Correct. In the HttpServlet base class, the service() method examines the HTTP request type. It calls doGet() if the request is a GET request and doPost() is it's a POST request. Presumably some of the other request types are also dispatched as well, but I haven't checked lately.
Customer surveys are for companies who didn't pay proper attention to begin with.
As was pointed out, these all represent methods of the underlying HTTP protocol. For many of my applications, both doGet and doPost simply turn around and call a custom "handleRequest" method I create, but if you're ever writing a servlet to handle REST ( http://en.wikipedia.org/wiki/REST ), those other methods suddenly become a lot more important!
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower
Randall Twede wrote:to try to answer briefly, why use post when you can use get. one is for short stuff the other is for longer stuff.
GET is for idempotent requests whose intent is to fetch the current state of a resource.
POST is for potentially non-idempotent requests whose intent is to perform an action.
I'd like to add that these rules are not as strict as that. GET has the limitation that all parameters go in the URL. That means that with many parameters, this URL becomes large; sometimes too large for the browser to handle (I've seen IE choke on a few myself). Also, all parameters are visible for the user. I myself find it justifiable to use POST for idempotent requests if the parameter list can become large or there is (semi) sensitive data in it.