9

I am maintaining a old .aspx page in which all the data required by the page to show the content is passed in the URL of the GET request as a part of query string. The result of this is that, as we keep on adding features, the URL keeps getting bigger.

I am thinking of shifting all the parameters from the query string to the Body of the GET request.

Is it a good design decision and what is the use case of a body in GET request?

  • 2
    Why not simply using a POST request instead? – πάντα ῥεῖ Jun 17 '18 at 9:12
  • 1
    Because I am not creating or updating anything. I am just retrieving info from the server. – kumarmo2 Jun 17 '18 at 9:12
  • 8
    It's expected that GET requests are idempotent: requesting the same URL multiple times always gets you an equivalent result. This e.g. allows for caching (which some browsers and proxies do very aggressively). If you move query parameters into the request body, you are violating this expectation so please avoid this. You're setting yourself up for hard to debug problems. Unfortunately, some systems have an URL length limit on the order of a few KB. If you are still designing your API and find that you will deal with very complex queries, a GraphQL API might be a better fit than REST. – amon Jun 17 '18 at 12:01
  • 4
    In addition to what @amon said, putting a body in a GET request is explicitly in violation of the HTTP spec. Use POST. – Eric Stein Jun 17 '18 at 12:07
  • 3
    @Manya The comments on this Stack Overflow answer discuss Elasticsearch a bit. Note that Elasticsearch is not typically consumed directly by browsers but only by internal applications, so they have a bit more flexibility – you have full control over the client and the network. – amon Jun 17 '18 at 14:57
8

GET requests with a body are supported in the HTML specs.

See the Stack Overflow question Is this statement correct? HTTP GET method always has no message body for a discussion.

However, it's unusual. You will surprise people with that solution. Simply switching to a POST is a better idea.

The only downside (upside?) is annoying RESTfulness acolytes.

| improve this answer | |
  • 1
    there are technical downsides since many javascript libraries don't support GET with a body. For databases where you are performing a search, it makes logical sense to do it that way, but you wouldn't be able to make the call from a single page app to your ElasticSearch or SOLR instance (the only APIs where I saw this combo implemented). – Berin Loritsch Jun 18 '18 at 14:18
  • 1
    This question says the same thing: stackoverflow.com/questions/978061/http-get-with-request-body "Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics. So, yes, you can send a body with GET, and no, it is never useful to do so. " The actual answer has more details. – Jerry Jeremiah Aug 26 at 5:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.