GET: Retrieving Resources

When you type a URL and press Enter, you're asking a question. That's all a GET request is—a question directed at a server, asking it to show you something. The server answers, you receive the answer, and nothing changes.

This simplicity is the source of GET's power.

The Question That Doesn't Change Anything

A GET request retrieves a resource. It doesn't create, modify, or delete—it only reads.

GET /api/users/123 HTTP/1.1
Host: example.com
Accept: application/json

The server responds with the answer:

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "Alice Johnson", "email": "alice@example.com"}

This read-only nature has a name: GET is safe. A safe method promises not to modify anything on the server. You're just looking.

GET is also idempotent—asking the same question ten times gives you the same answer ten times. Nothing accumulates. Nothing changes.

These two properties sound academic, but they unlock everything that makes the web fast.

Why Safety and Idempotency Matter

Because GET requests are safe, browsers can prefetch links you might click. They can speculatively load pages in the background. They can do this without asking permission because they know a GET request won't accidentally transfer money or delete files.

Because GET requests are idempotent, the Internet can retry failed requests automatically. If your connection drops mid-request, your browser can silently try again. Proxies can cache responses and serve them to thousands of users. CDNs can distribute content globally.

The entire caching infrastructure of the Internet depends on this contract: GET requests are questions, and questions don't change anything.

Refining the Question with Query Parameters

The URL path identifies what you're asking about. Query parameters refine the question:

GET /api/users?role=admin&status=active&page=2 HTTP/1.1

This asks: "Show me the second page of active admin users."

Query parameters handle filtering (status=active), sorting (sort=created_at), pagination (page=2&limit=50), and search (q=javascript). They're visible in the URL, which makes them perfect for bookmarking and sharing—but dangerous for secrets.

URLs appear in browser history. They show up in server logs. They leak through referrer headers. Never put passwords, API keys, or credit card numbers in query parameters.

There's also a length limit. Most browsers cap URLs around 2,000-8,000 characters. If you need to send more data than that, you need a different method.

Caching: The Payoff

Because GET requests are predictable, servers can tell clients exactly how long to remember the answer:

Cache-Control: max-age=3600

This says: "You can reuse this response for an hour without asking again."

For resources that might change, servers can use ETags—unique fingerprints for specific versions:

ETag: "abc123"

The next time you request that resource, you can ask: "Has it changed since version abc123?" If it hasn't, the server responds with 304 Not Modified—no body, minimal bandwidth, faster everything.

Static assets like images and stylesheets can be cached for months. API responses might be cached for seconds or minutes. The strategy varies, but the mechanism is the same: GET requests can be remembered because they're just questions.

When GET Becomes Dangerous

Violate the contract, and things break in surprising ways.

The prefetch disaster: A developer creates a link like /delete-account?user=123 that actually deletes the account when clicked. An email client prefetches the link to speed up loading. The account vanishes before the user even sees the email. This isn't hypothetical—it has happened.

The leaked secret: An API key goes into a query parameter for convenience. It appears in server logs, gets indexed by a search engine through a referrer header, and ends up in a security breach report.

The double charge: A payment confirmation uses GET because "it's just showing a receipt." A flaky connection causes the browser to retry. The customer gets charged twice.

The rule is simple: if the operation changes anything—creates a record, processes a payment, sends an email, increments a counter—it cannot be a GET request. Use POST, PUT, PATCH, or DELETE.

The Contract

GET is a question. It retrieves data without side effects. This promise enables caching, prefetching, automatic retries, and the entire performance infrastructure of the web.

Honor the contract, and you get speed and reliability for free. Break it, and browsers might delete your users' accounts.