Each request runs in a separate thread!

　　When you use GET, the parameter data shows up in the browser’s input bar, right after actual URL (and separated with a “?”). Still another issue is whether you need or want end-users to be able to bookmark the request page. GET requests can be bookmarked; POST requests cannot. That might be really important if you have, say, a page that lets users specify search criteria. The users might want to come back a week later and try the same search again now that there’s new data on the server.

　　But besides size, security, and bookmarking, there’s another crucial difference between GET and POST—the way they’re supposed to be used. GET is meant to be used for getting things. Period. Simple retrieval. Sure, you might use the parameters to help figure out what to send back, but the point is—you’re not making any changes on the server! POST is meant to be used for sending data to be processed. This could be as simple as query parameters used to figure out what to send back, just as with a GET, but when you think of POST, think: update. Think: use the data from the POST body to change something on the server.

　　An HTTP GET is just for getting things, and it’s not supposed to change anything on the server. So a GET is, by definition (and according to the HTTP spec) idempotent. It can be executed more than once without any bad side effects. POST is not idempotent—the data submitted in the body of a POST might be destined for a transaction that can’t be reversed. So you have to be careful with your doPost() functionality!