About doGet and doPost of Services

[Oprah Thaddeus]

I have this observation about doGet and doPost of the Services where we spend most of the time....coding

Now in netBeans I have noticed that they do this

    
    protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        PrintWriter out = response.getWriter();
        try {
            out.println("<br>Hello World");
        } finally { 
            out.close();
        }
    

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        processRequest(request, response);
    } 

    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        processRequest(request, response);
    }

My observation is the following. Is it not better this way? I mean this seems to have both doGet and doPost. And both are just calling the same method which doing the job...This might save the trouble of wondering whether the form has doGet or doPost. What do you think?

[shivendra tripathi]

doGet and doPost process Request in different way. To process Post request you may look the request body which you don't do in get request. In your case since you are not processing request it doesn't make any difference and you can have a default implementation called form doGet and doPost.

[Oprah Thaddeus]

shivendra tripathi wrote:doGet and doPost process Request in different way. To process Post request you may look the request body which you don't do in get request. In your case since you are not processing request it doesn't make any difference and you can have a default implementation called form doGet and doPost.

Can you explain bit more? :-) thanks

[shivendra tripathi]

Please ignore whatever I said earlier. Almost all API behave in the same way as shown in your code. The only difference I can see is, since doGet is idempotent so while implementing it you should make sure that there is no side effects of multiple submission of form. But that can be achieved using getMethod of HttpRequest API as well.

[Sony Agrawal]

shivendra tripathi wrote: since doGet is idempotent so while implementing it you should make sure that there is no side effects of multiple submission of form.

How can this be handled ... i mean the issue with multiple submission

[Ulf Dittmer]

I mean this seems to have both doGet and doPost. And both are just calling the same method which doing the job...This might save the trouble of wondering whether the form has doGet or doPost. What do you think?

The HTTP specification is very clear that GET and POST are to be used for different purposes; a servlet that uses them interchangeably is thus not in compliance with the HTTP spec, and -if GET is used for purposes where POST should be used, there will be problems. Don't do this.

[Ulf Dittmer]

Sony Agrawal wrote:How can this be handled ... i mean the issue with multiple submission

Form submissions should be done via POST, not GET. If someone then clicks Reload in the browser, it will warn the user that the form is about to be re-submitted. That's not the case with GET. The Post-Redirect-Get pattern avoids this particular problem (there's an FAQ page about that with more information).

[Oprah Thaddeus]

Ulf Dittmer wrote:

Sony Agrawal wrote:How can this be handled ... i mean the issue with multiple submission

Form submissions should be done via POST, not GET. If someone then clicks Reload in the browser, it will warn the user that the form is about to be re-submitted. That's not the case with GET. The Post-Redirect-Get pattern avoids this particular problem (there's an FAQ page about that with more information).

I think PRGP is not in the syllabus of SCWCD. However, I am really interested to find a very simple tutorial on this. Do anyone have a tutorial we can visually look at? Thanks

[Ulf Dittmer]

This article should help: http://www.javaranch.com/journal/200603/frontman.html