GET vs POST vs QUERY is a comparison of three ways to ask a server for something. GET reads data with its parameters in the URL. POST sends a body for the server to process. QUERY is a proposed method that reads data safely while carrying its query in a body. Each one says something different about what your request means.
The comparison matters most when you're building a search with a long, complex filter. GET starts to feel too small, and POST feels wrong because you aren't changing anything. This article explains each method, compares them on meaning, size, caching and real-world support, and ends with a simple rule for choosing.
- GET is for simple, safe reads that fit in a URL, and it caches easily.
- POST is for changes such as creating orders. It isn't safe, and it isn't idempotent by default.
- QUERY is a proposed IETF method: a safe, repeatable read with the query in the body.
- Choose by meaning first, then check that your whole stack supports the method.
- Until QUERY is widely supported, POST is the fallback for complex reads. Document those endpoints as read-only.
- 0:00Intro
- 0:23Three methods, one awkward gap
- 1:16GET: reads that live in the URL
- 2:12POST: a body to process
- 3:08QUERY: a safe read with a body
- 3:57Safe and idempotent: who can repeat?
- 4:51When the filter outgrows the URL
- 5:45Caching and retries
- 6:48Who speaks QUERY today?
- 7:33Building a shop: which method where?
- 8:22The rule of thumb
- 9:10What to remember
- 9:39Choose methods by meaning, not convenience
GET: reads that live in the URL
GET is the method behind almost every page load and API read. Everything the server needs is in the URL, and there is no meaningful request body. A product search might be GET /products?q=red. The address alone describes the whole request, so any tool that sees the URL knows what is being asked.
Suppose the connection drops halfway through. The browser can simply send the same GET again and receive the same 200 OK with the same JSON list. Nothing changed on the server the first time, so repeating the request does no harm. That predictability is the main reason GET is trusted by every layer of the web.
The URL also works as a natural cache key. A cache can store the response under that address and reuse it for the next identical request. This is a big part of why GET is fast and dependable.
- Safe: it shouldn't change anything on the server
- Idempotent: sending it twice has the same effect as sending it once
- Easy to cache: the URL identifies the response
POST: a request body for the server to process
POST works differently. The important part moves out of the URL and into the request body, and the server decides what to do with it. A typical example is POST /orders with a Content-Type header that says the body is JSON. The body might describe one pair of shoes, and the server creates an order from it.
Because the data travels in a body, POST can carry large, nested JSON, form submissions or files, and URL limits never get in the way. That flexibility is why developers reach for it so often, sometimes even for requests that only read data.
The trade-off is in what POST promises. It isn't safe, because it may change state on the server, so caches and other tools must assume it has side effects. It also isn't idempotent by default. If a retry repeats that order request, you could end up with two orders. POST is powerful for changes, but it's risky to repeat blindly.
- Structured body: large and nested data fits easily
- Not safe: it may create or change things
- Not idempotent by default: repeats can duplicate actions
POST /orders HTTP/1.1
Content-Type: application/json
{"item": "shoes", "qty": 1}What is the HTTP QUERY method?
QUERY is a method proposed at the IETF, the group that standardises HTTP. It is still a proposal, not something you can assume is supported everywhere. Its purpose is narrow and clear: give complex reads a method that is honest about being a read.
Imagine asking a shop for red shoes in size 9 under 50. With QUERY, the request is QUERY /products with a JSON content type, and the filter sits in the body. The Shop API reads data and never writes it. The filter can grow long and nested without being squeezed into a URL.
In short, QUERY offers GET's safety with POST's room. The server promises it is only reading, and repeating the request is harmless, so retries are fine. It is designed for the gap where GET is too small and POST says the wrong thing.
- Body like POST: room for long, structured filters
- Safe like GET: read-only and repeatable
Safe vs idempotent: which requests can be repeated?
These two words are more than labels. Browsers, proxies and retry logic make real decisions based on them. A safe method is read-only: the client isn't asking the server to change anything. The server might still write logs, but that is its own business and not part of the request's meaning.
An idempotent method is repeatable. Sending the request once or ten times leaves the server in the same state. When a method is both safe and idempotent, software can resend it automatically after a failure without asking anyone.
On this comparison, GET and QUERY tie, and POST comes last. GET and QUERY are both safe and idempotent, so they are safe to resend. POST may change state and isn't idempotent by default, so an automatic retry risks duplicating whatever it did.
- GET: safe, idempotent, safe to auto-retry
- POST: not safe, not idempotent by default, retries may duplicate
- QUERY: safe, idempotent, safe to auto-retry
What happens when a filter outgrows the URL?
There is no single official URL length limit. In practice, though, servers, proxies and browsers each impose their own limits, and those limits differ. A URL that works through one setup can fail through another.
Watch a filter grow. You start with ?color=red&size=9. Then you add a price range, such as &pricelt=50. Then a list of brands: &brand=a&brand=b, and on and on. Eventually a proxy refuses the request with 414 URI Too Long. Your request is still just a read, but it no longer fits.
Size isn't the only problem. Nested data in a URL needs brackets, percent-encoding and conventions that vary between tools. A body can carry the same filter as JSON with real nesting, arrays and types. On payload size, POST and QUERY win, and GET loses once filters get big.
Caching and retries compared
A cache can only reuse a response if it knows two things: what identifies the request, and that serving a stored copy is harmless. When a browser sends a request through a proxy cache, a hit is answered right away. A miss is forwarded to the API, which reads from the database, and the response can be stored for next time.
GET is the easiest to cache because the URL is the key and every cache already understands it. QUERY is safe and idempotent, so its meaning allows a cache to use the URL plus the body as the key. The cache itself has to support this, though.
POST responses generally aren't cached, and because POST isn't idempotent by default, retrying it is risky. For speed and reliability after the request is sent, GET leads, QUERY is promising, and POST trails.
- GET: cache by URL
- QUERY: cache by URL plus body, where the cache supports it
- POST: usually not cached
Is the QUERY method supported yet?
On paper, QUERY wins many rounds. The practical question is whether your software supports it. An HTTP request passes through many hands, and every one of them must recognise a new method before you can rely on it.
For QUERY to work end to end, it needs support from web servers, proxies, CDNs, frameworks, HTTP clients and API gateways. If any one of them doesn't support it, the request may be rejected or mishandled. GET and POST, by contrast, have been handled by every server, proxy, library and tool for decades, with no surprises.
So before you depend on QUERY, test your actual stack end to end. For now, GET and POST clearly win on support.
Example: choosing methods for an online shop API
Picture a shop app on web and mobile that sends every request to an API gateway. Each endpoint does a different kind of work, so each gets the method that describes that work honestly.
A simple product page goes to the Products API as GET /products/42. The filtered search goes to the Search API as QUERY /search, because it is a complex read. Checkout goes to the Orders API as a POST, which writes to the database, so POST is exactly right there.
If your gateway or clients don't support QUERY yet, use POST for the search as a fallback. Then document clearly that this endpoint is read-only, so the people and tools working with it know it has no side effects.
GET, POST or QUERY: which should you pick?
The rule of thumb is to choose by meaning, not convenience. Start with what the request actually does, then check that your stack supports the method you chose. Safe reads should never pretend to be writes, because caches, tools and retry logic all trust what the method says.
Pick GET for simple reads: a product page, a short search, anything that fits comfortably in a URL and benefits from caching. Pick POST for changes: creating an order, submitting a form, starting a job. Pick QUERY for complex reads with long, nested filters, once your servers, proxies and clients support it. Until then, POST is the fallback for those reads.
- Simple read that fits in a URL: GET
- Anything that creates, updates or triggers an action: POST
- Complex read that needs a body: QUERY, or POST until QUERY is supported
Key takeaways
- GET is for safe reads with parameters in the URL.
- POST carries a body and may change state, so repeats can duplicate actions.
- QUERY is a proposed safe, idempotent read that carries its query in a body.
- URLs hit practical length limits, so big filters belong in a body.
- GET caches easily and POST rarely does. QUERY can be cached by URL plus body if the cache supports it.
- QUERY still needs wide adoption, so test your whole stack before relying on it.
Frequently asked questions
Can I use POST for a search request?
Yes, and it's the usual fallback when a search filter is too large for a URL. Because POST doesn't promise to be safe, document that the endpoint is read-only. Once your stack supports QUERY, it describes that request more honestly.
Is QUERY an official HTTP method?
Not yet. QUERY is a proposal at the IETF, the group that standardises HTTP. Support depends on your servers, proxies, CDNs, frameworks, clients and gateways, so check them before relying on it.
What is the difference between safe and idempotent?
Safe means the request is read-only and doesn't ask the server to change anything. Idempotent means sending it once or many times leaves the server in the same state. GET and QUERY are both, while POST is neither by default.
How long can a GET URL be?
There is no single official limit. Servers, proxies and browsers each set their own practical limits, and those differ. When a URL is too long, you may get a 414 URI Too Long error.
Can QUERY responses be cached?
QUERY is safe and idempotent, so its meaning allows caching, with the URL plus the request body as the key. The cache you use has to support this.
Why shouldn't I just use POST for everything?
Caches, proxies and retry logic rely on what the method promises. A read sent as POST loses easy caching and safe automatic retries, because tools must assume it might change something.
