0

Is it recommended to send a JSON body via a POST HTTP Request which doesn't modify anything?

Based on the link below, a Get request is not recommended to have a body. Thus, the other way is the one above.

HTTP GET with request body

Example: Get the list of users, or anything for that matter based on parameters.

Http GET example.com/users
Body
{
 name:"John",
 age:1,
 ... long list of parameters
}
Pingpong
  • 7,681
  • 21
  • 83
  • 209
  • Why would it be a POST if it doesn't modify anything...? – esqew Oct 19 '21 at 14:56
  • If a request does not modify anything, why does it need a body? Can you provide a specific example? – SiKing Oct 19 '21 at 15:07
  • pls see example. – Pingpong Oct 19 '21 at 15:43
  • 1
    POST doesn't _need_ to modify anything AFAIK, it just _can_. I've seen POST being used in this case too, where the URL would become too big to take all possible filters into account. You could append `/search` to your path, e.g. `POST /users/search`, in the sense "create a new search". – sp00m Oct 19 '21 at 15:50
  • 1
    It certainly doesn’t *have* to modify anything (see the entirety of the SOAP protocol) but it wouldn’t be compliant with the HTTP spec and can cause significant confusion with developers trying to consume such a service. IMO, the most spec-compliant way to accomplish this would be to implement the route as a GET and use URL parameters to pass arguments for the information retrieval operation. Depending on the use case, you could implement a single URL parameter that accepts URL-encoded JSON, but that isn’t a particularly common pattern – esqew Oct 19 '21 at 16:48

1 Answers1

0

Is it recommended to send a JSON body via a POST HTTP Request which doesn't modify anything?

The rule is that POST is the default; it should be used unless there is something better.

For a request with "effectively read only" semantics, you want to use GET instead of POST... if it works. The challenge can be those cases where the request-target (aka: the URI) gets long enough that you start running into 414 URI Too Long responses. If your identifier is long enough that general purpose components refuse to pass the request along, then it is not something better, and you fall back to POST.

An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. (HTTP Semantics, 9.3.1)

In other words, introducing a private agreement to include content in a GET request trades away inter-op, which - if you want "web scale" - is not a winning trade. So GET-with-a-body is not better, and you fall back to POST.

The HTTP working group has been working on semantics for a new "effectively-read-only-with-a-body" method token, which could prove to be an alternative for requests where you need to include a bunch of information in the body because it is too long to encode it into the URI. But we don't have a standard for that today, which means that it is not something better, and you fall back to POST.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91