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

Sivaram Rasathurai
4 min readJan 4, 2025

→ 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..

Photo by Tommaso Pecchioli on Unsplash

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.

Sources

Responses (14)

What are your thoughts?

The risk of using GET with URL params is that you send sensitive data like an email address (or even worse) in the URL and most systems log the complete URL in a lot places. You may end up with security leaks and GDPR law problems!

I believe it's worth mentioning that RCF9110, which obsoletes RFC7231, discourages this use of GET with a body. Query parameters and header fields are more compliant with the purpose of the method and keep it cacheable.

Notes about the risks are helpful, thanks. One comment about animated gifts: Distrupting the focus