You're reading for free via Sivaram Rasathurai's Friend Link. Become a member to access the best of Medium.
Member-only story
Why POST with a Body for GET Is Bad Practice in REST
Stick to GET for retrieval and reserve POST for actions that create or process data
→ If you are not a medium member, read it here.
→ You can view my system design library here.
→ View my personal highly quality content java articles library here.
Lets Jump into the Blog..
The HTTP GET method is typically used for retrieving data, and many developers assume it doesn’t support a body. But the truth is, GET requests can include a body. According to the standard (RFC 7231 §4.3.1), GET requests can have a body, but the body has “no defined semantics.”

Is it a good idea to use GET with a body? → depends on your use case.
When GET with a Body Works
GET /items
{ "ids": [1, 2, 3, ..., 1000] }
1. Direct Communication Between Client and Server
If your API is designed for direct communication between the client and server, with no intermediaries (like proxies or caches), using GET with a body can work well.
- The server can process the body correctly.
- No intermediaries mean no risk of the body being dropped or misinterpreted.
2. Specific Use Cases in APIs
Some systems already use GET with a body for advanced queries, such as:
- Elasticsearch supports GET with a body for structured searches.
- GraphQL APIs sometimes allow queries in GET bodies for better caching.
3. Retaining REST Semantics
If your use case strictly involves fetching data (no side effects), using GET with a body allows you to adhere to REST principles, as GET is designed for data retrieval.
Why GET with a Body Can Be Risky
While GET with a body works in controlled environments, there are risks:
1. Intermediary Issues
If your API ever interacts with proxies, caches, or other intermediaries, they may:
- Drop the body entirely.
- Ignore the body, leading to incorrect responses.
- Misinterpret the request, causing errors.
2. Caching Challenges
HTTP caches use the URL and method to determine what to cache. If the body contains essential parameters, caches won’t account for it, leading to inconsistent behaviour.
3. Limited Adoption
Not all tools, libraries, or frameworks support GET with a body. Some might reject it outright.
4. Security Risks
If the body contains sensitive data, intermediaries might log it or expose it unintentionally.
When to Avoid GET with a Body
1. Public APIs
If your API is exposed to third-party clients or the open web, avoid GET with a body. You can’t control the intermediaries between the client and your server.
2. Complex Systems
In distributed systems, where proxies, gateways, or CDNs may be involved, GET with a body is unreliable.
Alternatives to GET with a Body
If GET with a body isn’t feasible, here’s what you can do:
1. Use Query Parameters with GET
For smaller data payloads, stick to query strings:
GET /products?ids=1,2,3,...,1000
- Cache-friendly.
- Reliable across all systems.
If the payload is too large, split the request into smaller chunks by client:
GET /products?ids=1,2,3,...,100 GET /products?ids=101,102,103,...,200
2. Request Body with POST
using POST with a request body for data retrieval can violate REST principles and create unnecessary confusion. REST is built on the idea that GET is for retrieval and POST is for creating or processing data.
Take Aways
- Use GET with a Body Sparingly: Only in environments where you control the client and server and no intermediaries exist.
- For Public APIs, Avoid GET with a Body: Stick to query parameters or POST for compatibility and reliability.
- Document Clearly: If you decide to use GET with a body, document your API behaviour to avoid confusion among users.
GET is the right choice for retrieving data, even when handling large or complex requests.
GET with a body can work, but only in controlled setups with no intermediaries.
POST for data retrieval should be avoided, as it complicates API design and violates REST principles
What’s your take? Have you used GET with a body successfully? Or do you think it’s a mistake waiting to happen? Let the discussion begin!
Since you read this article until now, you would like this API Versions Article as well.
Notable Discussions from Other Developers
Update: RFC 9110 Clarification
A Special thanks to Denys Sene for pointing out this clarification and contribution the discussion.
RFC 9110, which supersedes RFC 7231, explicitly discourages using a body with GET requests. According to the standard, while GET requests can technically have a body, the semantics are undefined, and its usage is uncommon.
Instead, query parameters or header fields are recommended for passing data, as they align better with the purpose of GET and help maintain its cacheability.