Why are url query strings is superior to the values in the body?
There are some obvious differences between the two ways to request data - like being able to see the parameters in the url, or the fact that the requests can be saved in the brower's history.
But is there anything more to it? Is it bad to request data with body?
There's nothing wrong with using a body. GET method does not have a body not because of some prejudice against the usage of body.
If you have a look at the HTTP protocol specification, you might have some insight:
"The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI."
In simpler words, GET method is created to retrieve some resource using only URI. In even simpler words - if you can get some resource using only URI - GET is a method you should use.
As a matter of fact, you can send body with GET request, but it will be just ignored (more information here: HTTP GET with request body)
If you need to pass a body for whatever reason you will need to use a different method. POST is a prominent example:
"The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line."
If you are working on REST API's I would highly encourage to read HTTP specification https://www.rfc-editor.org/rfc/rfc2616
Is it bad to request data with body?
Yes, it is bad.
The problem is that, in HTTP, GET method is specifically defined to not to include a request body.
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. -- RFC 7231
What's going on here, largely, is that early versions of the HTTP specification had some ambiguities about the handling of message-bodies in requests. In effect, putting a message-body into a GET request was "undefined behavior".
The working group is strongly motivated to ensure that the standard remains backwards compatible.
Part of the point of REST is that we are all using a common standard, so that the general purpose tools (browsers, caches, reverse proxies, spiders...) work for everybody -- or more specifically for everybody that abides by the standard.
With regards to GET, including a message body doesn't make sense when you consider caching semantics. Caching semantics in HTTP are currently defined by RFC 7134, the high level summary is that the target-uri is the primary cache key; caches only need to understand the metadata in the HTTP request to do their job properly.
If we were to apply semantics to the body of a GET request, we'd also need to define, in a general way, how those semantics affect cache behavior.
For instance, if you imagine a query scenario (like GraphQL), the expected representations in the response depend on the information encoded into the request body. So now you need to start defining when two request bodies are "the same" - is white space significant? does the content encoding matter? what about if the body is zipped? and so on....
We don't have this kind of problem with unsafe requests (for example, POST), because standards compliant caches MUST write through requests that are unsafe. There's no need to explore the representation of the message-body of the request because there are no circumstances where the contents would change this requirement.
There have been attempts at creating a new standard for the HTTP method that is safe and includes a message body. It's probably doable; in the sense that we introduce a new method token, and declare the semantics to be safe (so that we can perform preemptive fetching, and repeat requests on an unreliable network) and perhaps that public caches cannot store the responses, but must instead forward each request to the origin server.
That said, people have been aware of the gap for a while, and the problem doesn't yet have a standardized solution - so there may be some difficult aspect to it that isn't obvious (in addition to the political problems of adoption vs inertia).
