GET vs POST: Uncover the Real Differences Behind HTTP Requests
While many developers can list superficial distinctions between GET and POST, this article delves into the underlying TCP mechanics, browser and server constraints, and practical implications, revealing why the perceived differences exist and how each method truly operates in real‑world web applications.
GET vs POST Overview
GET and POST are the two fundamental HTTP request methods. The most obvious difference is that GET places parameters in the URL while POST sends them in the request body.
When asked in an interview, many can recite a “standard answer” that lists several practical distinctions:
GET is safe for browser back navigation; POST may resubmit.
GET URLs can be bookmarked; POST cannot.
GET responses are cached by browsers by default; POST is not unless manually configured.
GET supports only URL‑encoded data; POST supports multiple encodings.
GET parameters appear in browser history; POST parameters do not.
GET URLs have length limits; POST does not.
GET accepts only ASCII characters; POST has no such restriction.
GET exposes parameters in the URL, making it less suitable for sensitive data.
GET sends parameters via URL; POST places them in the request body.
The “standard answer” is often sourced from w3schools, but it does not tell the whole story.
The Underlying Reality
Both GET and POST are built on TCP/IP; at the transport layer they are identical TCP connections. Technically you could add a request body to a GET or URL parameters to a POST, and the protocol would still work.
The differences arise from HTTP specifications and practical limits imposed by browsers and servers. Browsers typically limit URL length to about 2 KB, while many servers cap URLs around 64 KB. Servers may also reject or ignore bodies in GET requests.
Transport Analogy
Think of TCP as a reliable delivery truck. HTTP defines service types: GET places the payload on the truck’s roof (URL), POST puts it inside the cargo hold (body). GET usually requires a single round‑trip, while POST involves a two‑step handshake (header, 100 Continue, then body), effectively sending two TCP packets.
Practical Implications
GET and POST have distinct semantics; they should not be interchanged arbitrarily.
In good network conditions the extra round‑trip of POST is negligible; in poor conditions the extra verification can improve reliability.
Not all browsers send two packets for POST (e.g., Firefox may send only one).
Understanding these nuances lets you answer interview questions with depth rather than reciting a memorized list.
Efficient Ops
This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.