This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
Joined: Feb 15, 2012
Please explain me why do they call doPost() in doGet() method ,in the following programs........ and why do we use doprocess() method???
Joined: Mar 22, 2005
Because "they" -whoever they are- are bad developers who have no clue about web development. Don't trust "them" with anything important.
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.
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.
Joined: Mar 22, 2005
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.)
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. ;)
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.
Joined: Mar 22, 2005
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.)
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.
In preparing for battle I have always found that plans are useless, but planning is indispensable. -- Dwight D. Eisenhower
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.
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.
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.)