• Post Reply Bookmark Topic Watch Topic
  • New Topic

Difference between GET and POST

 
A Bhattacharya
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there any difference except the length restrictions in case of GET? Ofcourse you generally use POST for submitting data to the server but this is more of a convention than a firm requirement. I told this answer to the interviewer but he seemed to be expecting more differences.
 
Pankaj Tiwari
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
one more point could be that in post the data is passed as message body.
 
Pankaj Tiwari
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.cs.tut.fi/~jkorpela/forms/methods.html

good link to go through, it explains great details
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
... more of a convention than a firm requirement

The semantic difference between GET and POST (and other methods) is in the HTTP spec, a bit stronger than "convention." I've seen many "front controller" designs ignore the intentions of the founding fathers and run GET and POST through the same code. Feels convenient but just plain wrong to me.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
I've seen many "front controller" designs ignore the intentions of the founding fathers...

But is it really the responsibility of a front controller to enforce this? Or is it up to a developer to exhibit discipline?

There are cases where one can't always follow the rules; for example; a GET request that must be submitted as a POST because the length of the parameters exceeds the limitation of a query string.
 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bear Bibeault:
There are cases where one can't always follow the rules; for example; a GET request that must be submitted as a POST because the length of the parameters exceeds the limitation of a query string.


So far I have not been able to find in the HTTP specification anywhere where it prohibits a GET request from having a body. Presumably if your problematic request is really an idempotent GET (and not a side-effect POST in disguise) than you could potentially specify these long parameters in a GET body.

Of course, if you are limiting yourself to a generic browser as a client, then supplying a body for a GET may not be feasible, but it is important that HTTP is a general purpose protocol, not just the way that IE, Firefox and Safari talk to a server.

In practice, a better solution is almost always to find a way to reduce the number and length of the GET parameters to a minimum representation of the resource being got.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I was speaking regarding the most common cases (requests initiated by the browsers).
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maintaining a separate doPost and doGet method is only one way of differentiating between the two.

The servlet spec also provides request.getMethod
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
a GET request that must be submitted as a POST because the length of the parameters exceeds the limitation of a query string.


Rules are meant to be broken, but that would make me uncomfortable. I was reading a RESTafarian thread the other day about a query with many parameters. Someone suggested POST on a "query spec" and then GET using the spec. Ick. Following the rules can be ugly, too.
 
Dale DeMott
Ranch Hand
Posts: 515
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
get posts the data back to the server via the http string and thus can be bookmarked.

get
http://www.mypage.com?parameter=1

post puts the data in the body of the http request and is not visible. The data being posted back to the server can't be bookmarked. also post can store more data while get has a size that is much smaller. each size requirement would be determined by the server.

post
http://www.mypage.com
no data saved in the url string
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
108
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't get me wrong. I'm not saying that it's not important to use GET and POST as correctly as possible -- my question was more along the lines of the responsibility of a Front Controller. Is it appropriate for the rules to be enforced by the FC, or is it something that the programmer should decide?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting point, Bear. I usually prefer "enable" over "enforce" because it's so much easier to code and shows a little trust in future developers.

I just made an experiment in REST over a front controller (no choice in using it) that treats GET & POST the same and doesn't even preserve the original method. I made a filter sitting in front of it that saves off the method. But because browsers usually can't generate PUT or DELETE, I also allow a method override on the URL. One could POST a form, override the method to GET and fool the rest of the app completely. That "enables" some rule-breaking.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
... and doesn't even preserve the original method. ...


I would think that a front controller would have to go out of its way not to preserve the method. Does it wrap HttpServletRequest and override getMethod to do something other than return the original method?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right there. The framework isolates access to HttpServletRequest to a fairly thin layer of classes that copy request parameters to beans, but we could get the original method in that layer.
 
Ben Souther
Sheriff
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:
... The framework isolates access to HttpServletRequest to a fairly thin layer of classes that copy request parameters to beans, but we could get the original method in that layer.

Ick!

If you get a chance, download and play with a copy of Bear's Frontman library.
It's smart enough to realize that the Servlet and JSP specs provide 9/10ths of a framework on their own and doesn't try to abstract them or re-invent any wheels.
Several of the staff members here are using for their own projects and have had good things to say about it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!