dopost() and doget() methods

[nagul samy]

Hi......,
Why do we call dopost() method in doget() method in a class which extends HttpServlet class..???

[Matthew Brown]

You don't call them, you override and implement them. You implement doPost to respond to POST requests, and you implement doGet to respond to GET requests.

[Ulf Dittmer]

As regards your question, neither method should call the other - the HTTP spec is quite clear that GET and POST are for different purposes. So any implementation that uses them interchangeably is in violation of the HTTP spec - a bad thing to do.

[nagul samy]

Please explain me why do they call doPost() in doGet() method ,in the following programs........ and why do we use doprocess() method???


1)

public void doGet(HttpServletRequest request, HttpServletResponse response) {
		doPost(request, response);
	}

	public void doPost(HttpServletRequest request, HttpServletResponse response) {
		try {
			SessionManager sessionManager = SessionManager.getInstance();
			sessionManager.buildBusinessObjects();
		} catch (Exception e) {
			e.printStackTrace();
			try {
				request.setAttribute("error", e.getMessage());
				request.getRequestDispatcher("../../error.jsp").forward(request,response);
			} catch (Exception e2) {
				e2.printStackTrace();
			}
		}
	}

2)

protected void doGet(HttpServletRequest req, HttpServletResponse resp)
			throws ServletException, IOException {
		doProcess(req, resp);
	}

	protected void doPost(HttpServletRequest req, HttpServletResponse resp)
			throws ServletException, IOException {
		doProcess(req, resp);
	}

	protected void doProcess(HttpServletRequest request,
			HttpServletResponse response) {

		try {
......
......
.......
}

[Ulf Dittmer]

Because "they" -whoever they are- are bad developers who have no clue about web development. Don't trust "them" with anything important.

[Guy deLyonesse]

Ulf Dittmer wrote:Because "they" -whoever they are- are bad developers who have no clue about web development. Don't trust "them" with anything important.

Well that could be...

...or it could be that we're seeing an incomplete program with no idea what context it's in, and that calling whoever wrote that a "bad developer" and saying they have no clue is premature and unfair. Is this a "friendly place for programming greenhorns" or isn't it?

nagul, What "they" appear to be trying to do here is implement a servlet that handled all requests in a single, generic manner. I've seen programs like this in some intro to servlet programming contexts. (although not with the doProcess method.) What they'd do is make the servlet able to handle POST and GET requests the same way, and if the servlet is simple enough, they can get away with it. Basically the reason for overriding and implementing them is because this is where the servlet's work is done, and there are several different types of HTTP requests so the servlet needs to know how to handle the ones you expect to receive in your app. I'd recommend getting a good book on how to write servlets and familiarize yourself with how they work. Then, when you go to build your own, you'll know which methods you need to override and implement.

[Matthew Brown]

Well, they're both trying to achieve the same result, which is to let the servlet respond in identical ways for both GET and POST requests.

Sidestepping the question for a moment of whether that's ever a good idea - I'd say the first example is much worse practice than the second. I think the second makes it clearer what's going on, but it also doesn't couple the doGet() and doPost() methods as closely. In the second approach, if you decided later that doPost() should behave a bit differently - say by doing something else at the end of the process - then you can add it without problems. In the second you'd also be adding the behaviour to doGet() - possibly without realising that.

So never call doGet and doPost yourself, but there may be times when it makes sense to factor out common behaviour into another method that they both call.

[Ulf Dittmer]

Violating fundamental specifications is in my book an indication of a bad developer at work. I don't see how more context could change the fact that that is what's going on here. (Also note that we're talking about an absent 3rd party, not a Ranch member.)

[Guy deLyonesse]

Hardly fundamental. Some places actually teach that approach if the two methods are to handle a request the same way. I wouldn't do it that way, but mine is not the only way things are done. I've known developers who could code rings around most of us here who have done it that way, so I'd be hesitant to accuse them of not knowing what they're doing.

Besides, I was unaware that being friendly only applied to forum posters. In my thinking friendly is friendly. Period. You never know. The OP might have written that code himself, and was shy to admit it. Maybe a co-worker wrote it. Maybe the author DOES post here sometimes. I don't know about you, but my ESP isn't that good. ;)

[Paul Clapham]

Guy deLyonesse wrote:Some places actually teach that approach if the two methods are to handle a request the same way. I wouldn't do it that way, but mine is not the only way things are done. I've known developers who could code rings around most of us here who have done it that way, so I'd be hesitant to accuse them of not knowing what they're doing.

But there are almost no cases in which a GET and a POST request to a resource should be handled in the same way. I believe most people do that because they have no idea of the difference between GET and POST. I'm one of those developers you describe who did it that way, but that was in fact because I didn't know what I was doing. Now I do know what I'm doing (in this particular case anyway) and I don't ever do that any more, because I don't ever have a case where a GET and a POST request should do the same thing.

And if you want to go with "hate-the-sin-but-not-the-sinner" I would say it's a bad practice.

[Ulf Dittmer]

We're talking about web development here - how much more fundamental than HTTP can you get?

HTTP implementations (like web browsers, proxies, servers etc.) are perfectly justified in handling GET and POST differently -even encouraged to do so by the HTTP spec- so any code that assumes they're interchangeable is a bug waiting to happen.

(BTW, I don't have ESP either :-) But I have been hanging around these forums for a long time and have seen a lot of crappy code that got posted here straight out of a tutorial written by someone who considered themselves an expert but weren't. While I can't be sure, I wager dollars to donuts that this is such a case.)

[Pete Nelson]

Okay ... an example.

Pointy-Headed Boss says "I don't want all that crap in the URL. Make it go away". So, since he's paying me to do the work, I make a POST method work like a GET method, and then spend my pay on beer and try not to think about it.

And yes, both my doGet(...) and doPost(...) methods end up calling "handleRequest(HttpServletRequest, HttpServletResponse)". It's OOP, even if it's not the most graceful HTTP.

[Bear Bibeault]

The requirements of a pointy-haired boss are hardly justification for throwing proper use to the wind. Sure it might have to be that way to continue participating in The Salary Continuation Program, but that doesn't make it right.

Sure I've been guilty of mashing GET and POST together in the past -- likely we all were. In fact, FrontMan doesn't make any distinction between the two, leaving it up to the command instances to do the right thing on their own (if there's every another version of FrontMan that would be remedied).

But this is 2012 and we're collectively a lot smarter than we used to be. Let's continue to urge people to do the right things. (Heck, just look at the JSP forum and see how many people are still putting scriptlets into JSPs ten years after they've been discredited!). It's an ongoing challenge.

[Ulf Dittmer]

I'd say responsible professionals need to make a stand against PHBs who don't know technology.

Making a POST do the work of a GET isn't as bad as the other way around; it may just put unnecessary strain on the server by preventing caching. The danger is in doing this unreflectedly (as, I suspect, in the code sample that prompted the original question). Having a GET do non-idempotent operations is asking for trouble.

[Guy deLyonesse]

Hey guys, don't get me wrong, I'm not sticking up for writing servlets that way. (Honestly, I don't really care how that debate would turn out anyway. I rarely write servlets. I'm more of a JSF/portlet kind of guy.)

What I'm trying to say is that I've always thought of this as a forum where even stupid questions can get answered without belittling anyone. (And we ALL ask stupid questions sometimes. All of us. Anyone who denies that is probably kidding himself/herself ;) )

Do you guys know how rare that is? If you need some examples of the other side just head over to the Oracle forums.... sheesh... Talk about rude. That's why I like this place better. My fear? That it'll start to become like other places where "experts" go to parade their egos, not to help beginners. (Not accusing anyone here of that, just letting you know where I'm coming from.)

/soapbox

[Bear Bibeault]

I see no belittling of a member. Unless you're of the camp that thinks that correcting someone is belittling them. But pointy-haired bosses deserve to be belittled

[Guy deLyonesse]

Bear Bibeault wrote:I see no belittling of a member. Unless you're of the camp that thinks that correcting someone is belittling them.

Does it have to be a member? Are we saying it's cool to be nasty so long as it's to the OP's buddy and not the OP himself?

Bear Bibeault wrote:
But pointy-haired bosses deserve to be belittled

You'll get no argument from me on that ;)