We talked about other issues with GET in chapter one, remember?
When you use GET, the parameter data shows up in the browser’s input bar, right after actual URL (and separated with a “?”). Imagine a scenario in which you would not want the parameters to be visible.
So, security might be another issue.
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.
And that brings up another issue... whether the request is idempotent. If it’s not, you could get into the kind of trouble a little blue pill can’t fix. If you’re not familiar with the way the term “idempotent” is used in the web world, keep reading...
Get Head First Servlets and JSP, 2nd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
