No, it’s not just about the size

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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access