Here I am going to discuss about whether it is a good idea to send parameter in request body of the HTTP GET request or not. Request body is also known as payload of the request. I will also discuss about idempotent and safe http methods.
Generally payload in the body is sent for POST, PUT, etc. http methods where you need to create a new resource or update the existing resource in server side.
When you are doing an http GET request on an entity, you are actually requesting or fetching the content of the entity. If you want to add some parameters (for example sorting a list in ascending or descending order), you can add these parameters in the query string. This query string contains one or more query parameters.
Alternatively you may also want to specify these parameters in the request body in GET request. HTTP/1.1 does not seem to explicitly forbid this when you want to send request body in GET request.
The questions is Whether request body is allowed in GET request? or Will HTTP client have any issue using request body with a GET request?
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as an entity in the response and not the source text of the process, unless that text happens to be the output of the process. The more information could be found here.
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Caching would be useless if it does not significantly improve performance.
The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; an “expiration” mechanism is used for this purpose. The latter reduces network bandwidth requirements; a “validation” mechanism is used for this purpose. The more information can be found here.
Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
Like HEAD, the GET method should not have the significance of taking an action other than retrieval. So HEAD and GET methods ought to be considered as “safe”.
However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that sequence are idempotent.
A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a re-execution of all, or part, of that sequence. A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).
A sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.
So, I have talked basic idea about GET method and if you need more clarification then you can always read it through the links given above.
Yes, you can send a request body with GET but it should not have any meaning. If you give it meaning by parsing it on the server and changing your response based on its contents, then you are ignoring this recommendation in https://tools.ietf.org/html/rfc2616#section-4.3.
As we previously stated The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI, which states that the request-body is not part of the identification of the resource in a GET request, only the request URI.
I have also said that the GET method should not have the significance of taking an action other than retrieval.
A message-body MUST NOT be included in a request if the specification of the request method does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request https://tools.ietf.org/html/rfc2616#section-4.3.
Let’s say you want to bookmark your URL or copy URL and want to send it to your friend. But you won’t be able to do this when you use request body with GET request.
Most intermediate infrastructures completely dropped the payload or request body from http GET request. Another issue is, caching headers would fail to function, because the outcome would be dependent on the request body. So, GET is solely for retrieving a representation based on the URL and a set of accepted headers.
The primary cache key consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching responses to GET, many caches simply decline other methods and use only the URI as the primary cache key https://tools.ietf.org/html/rfc7234.
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request https://tools.ietf.org/html/rfc7231#section-4.3.1. So, there are proxies out there that will definitely break your request in various ways if you include a body on GET.
All together it is suggested that when processing a GET request, a server is not required to examine anything other than the Request-URI and Host header field.
In conclusion, the HTTP specification doesn’t prevent you from sending a message-body with GET, but there is sufficient ambiguity whether it would be supported by all servers.
Hope the above explanation gives some light whether you need to use payload or not in the request body of the http GET request.