Performance wise both are almost equal, but features wise we can differentiate these methods:
The request type is GET
It will show the parameters in the request URL, like as http:...../login.do?name=baji,password=***
The length of the query string(i.e URL) is limited
The request type is POST
It'll hide the requests parameters
The length of the query string(i.e URL) is much length than GET
More secure than GET
As far as speed goes, a GET request is generally going to be physically smaller, so it will take less time to deal with. But that's only the tip of the iceberg. A get request that kicks off a major server-internal operation is going to lose that edge, and the size of the response is potentially the same for both GET and POST. So picking one over the other for performance reasons alone is a waste of time.
the size of the character is sending doget method in the get request will go through the header thats ways its limltation
postmethods requests user entered information is send as adata(not append to url) can send any of data in post the request will go through the body
You're partially incorrect. An url looks like this: scheme://domain:port/path?query_string#fragment_id e.g. http://coderanch.com/forums?something=lalala. yet the only part needed for routing is the "coderanch.com" part. The rest isn't necessary for that and is in fact encrypted. Easy to understand example I found: here.
Tim Holloway wrote:I, too am curious about how POST and GET are equally insecure. If I'm not mistaken, when TLS is active, the body (headers, cookies, POST contents, etc.) are encrypted, but the URL cannot be because otherwise it wouldn't be routable.
The reason why (in theory) even the protocol/hostname/port should be encrypt-able is because the actual tcp/ip network communications protocol carries the IP address and port number in the packet header. If the destination port is set up for TLS (like port 443 and 8443 usually are), then the payload can be fully encrypted, including the GET command string. I think the plaintext hostname in the sample dump isn't actually part of the encrypted payload, but I'm too lazy to pull out tcpdump and verify it.
singh gaurav wrote:GET sends data in name vale pair ,POST uses a Stream
This is not accurate. GET params are encoded as name/value pairs on the query string, but POST can also be name/value pairs encoded into the body. In fact any textual data can be sent in the body, not a "stream" (whatever that means). The body could be XML, could be JSON, could be the Base64 encoding of a binary blob -- just about anything that's text.
GET is More fast but not secure,
Once again, GET is not "more fast". Any processing differences between a GET and a POST sending the same amount of data and processing the same way on the server will be completely trivial.
GET method can carry only 1024 bit of data
That actually depends upon the browser.
consider this one "Now i can control a air craft ,a ship, fighter plane, a F1 car , a bus , metro train, super fast bullet train and all other many more things " by using my mobile phone in a single time instance but i need to update my mobile ..............
what it means ... in the same way you can secure a GET method / can send a xml/ or send name value pair via Post method...but you have to do a lot of complex implementations ,,,,,,,,,,,,,,,,,,,,,,,, hope you got my point ... and i am not expecting such type of comment from a very respected and a experience person....
[Not nice portion removed]
singh gaurav wrote:and i suppose whatever i am saying here is true ...
Sorry, no, There were factual errors in your post.
You stated that GET is faster than POST. Not true. It all depends on what the requests are doing, and if they are doing the exact same thing, the processing time will be so close as to be considered the same.
You stated that GET is not secure. POST is also not secure. No request is secure simple based upon the choice of method. Requests are secure by using SSL.
You stated that POST uses a "stream" while GETs use name/value pairs. POSTs store a text block in the body (which can be name/value pairs) not a s stream. Perhaps you are thinking about how the Servlets API allows you to read the POST body using a stream, but the content of the POST body is just text.
I'm sorry if it makes you feel bad to be corrected, but what you posted was not accurate and could be misleading to the novices in the audience.