Can You Perform a POST Operation Using a GET Request?🧐
Back when I was attending my 2nd year at A2SV, I was minding my own business when I overheard one of our mentors and his colleague talking about system design. His colleague had an upcoming system design interview and was preparing for it. Our mentor had already secured a full-time position at Bloomberg, so he was sharing some advice and helping him prepare.
Then I heard something that caught my attention.(Fast forward, they are both in Bloomberg now)
His friend asked:
“It’s possible to do a POST request using a GET request, right?”
I was like, wait what?😳 That question stuck with me.
How is that possible? And more importantly, why shouldn’t we do it?
That curiosity eventually led me to dig deeper into how HTTP actually works.
💻The Mechanics: How GET Can Act Like POST
At the wire level, an HTTP request is just a text block sent over a network socket. The server receives the text, reads the verb at the beginning, and decides how to parse the incoming data.
app.get("/create-user", (req, res) => {
const { name, email } = req.query;
// Insert into database
createUser(name, email); res.json({ message: "User created" });
});Now a client sends:
GET /create-user?name=Alex&[email protected] HTTP/1.1
Host: api.example.com
The backend reads the query parameters:
req.query.name
req.query.email
and inserts them into the database.
So even though the HTTP request is:
GET /create-user
the operation performed by the application is a create operation.
Data via Query Parameters: A
GET request can attach payloads directly into the URL query string. If a backend handler reads req.query and inserts those values into a database, a GET request has effectively performed a create operation (POST).Payloads in GET Bodies: While unorthodox, the HTTP specification does not strictly forbid a body inside a
GET request. If a server framework parses the body of a GET request and executes a data-altering query, it creates or updates records identical to a POST or PUT request.🙅♀️Why You Should Avoid Using GET for POST Operations
While technically feasible, bending HTTP semantics creates severe architectural and security risks:
1️⃣URL Logging and Leakage: Query parameters are logged in plaintext across browser history, web server access logs, load balancers, and CDN networks. Passing sensitive creation payloads (passwords, PII, tokens) inside a
GET URL exposes data to third-party loggers.2️⃣Aggressive Caching: CDNs and browsers assume
GET requests are idempotent and safe to cache. If a GET endpoint creates a database resource, edge servers might serve a cached response instead of hitting your backend, causing silent data failure.3️⃣Pre-fetching and Crawlers: Search engine web crawlers and browser pre-fetching engines automatically follow
GET links. If a GET request mutates state, a search crawler indexing your web app could unintentionally trigger database modifications or account deletions.4️⃣Violation of Idempotency: According to RFC 9110,
GET is defined as a safe method intended purely for retrieval without side effects. Breaking this contract leads to unpredictable behavior in distributed microservices and API gateways.✍️prepared it using AI
@veiledDev14
