1

GET and POST are supposed to be two different verbs, and their purpose is different. However, they come with implementation baggage which causes a lot of confusion.. there is often a tendancy to avoid GET even just because the parameters show up in the url.

Are there any good reasons why a GET parameters should be part of the url string and POST parameters should be part of the body of the request.

My question is:

  1. Shouldn't it be allowed to use either body or url string for any of the methods? Why is it that GET parameters have to be in the url.
  2. Is there a way to implement GET with parameters in the body (even from a rest client.. not browser)?

(Question relates more to REST but also generally to HTTP)

Updated: There's a more elaborate discussion here: HTTP GET with request body

Community
  • 1
  • 1
Teddy
  • 4,009
  • 2
  • 33
  • 55

4 Answers4

1

There are browser- and server-based restrictions on URL length that limit the amount of content that can be placed in the URL. The body of the request has no such restriction. The URL is also restricted in terms of what characters are allowed, with special characters being translated to their ascii equivalents.

A GET operation is typically (and prescriptively) used to retrieve information and can usually be parameterized with a relatively small set of search terms that tend to fit a simple key=value scheme that can be readily encoded in a URL query.

A POST has broader application and is generally used to send persistent data to a server (in fact, prescriptively GET should not be used for this purpose). If you consider a web form, say for user registration, it may contain fields for name, address, email address, a bio that you want other users to see, and the url of your webpage. Both in volume and form of content, this is not well-suited for inclusion in a URL.

The use of body for POST and URL for GET is really for consistency of convention and reflects the different needs of the respective use cases. There is no reason that POST couldn't use the URL to encode information except that there are many cases in which the URL would not be suitable for POST content, and so for consistency of convention the body is used for POST, while GET is restricted to URL to reflect the implied "functional" contract of retrieving content from a specific provider given a set of input parameters.

T3am5hark
  • 856
  • 6
  • 9
  • Thanks! However reverse is not true for GET. POST can still send data in url, but GET cant use the body. Why shouldn't GET support sending say 500 bytes in body? – Teddy Jun 22 '14 at 16:44
  • GET is meant specifically to retrieve data in a way that does not change state or persist any data on the server. It would be a rare case in which 500 bytes of body text would be needed to parameterize a retrieval operation. Again, there's no reason that you couldn't mix and match since GET and POST each have URL and body, but it's the convention that is used and helps to enforce the idea that "GET should be used for ABC" and "POST should be used for XYZ". Good point re: POST vs. GET - I modified tail of the answer for clarity / completeness. – T3am5hark Jun 22 '14 at 16:54
  • The URI is supposed to be the resource you are working on. As such, the URI having query parameters makes no sense for POST, as you are (supposed to be) making a **new** resource. As stated in this answer, your GET should be able to specify what it wants purely by the URI, this also helps with caching, as you can look at just the URI to know if it is resource that is already in the cache. – thecoshman Jun 22 '14 at 17:18
1

Both GET and POST can use parameters in the URI. There are no restrictions here.

Only POST can use parameters in the payload. GET can theoretically have a payload, but in practice it is ignored and might be lost in transit (broken HTTP stacks or intermediaries).

Julian Reschke
  • 40,156
  • 8
  • 95
  • 98
1

The HTTP RFCs define GET such that it is composed of the UrL abd other headers, and terminated by two newline chatacters. The URL scheme is defined by RFCs to include a special format for passing paramters as part of the URL. Web servers and browsers are specufically designed to comply with these standards, and so they are both defined standards and defacto standards.

In theory, headers could be used to pass paramemters between the client and serve.Except for cookies, this is nonstandard behavior that is not available through most clients.

HTTP POST is defined by RFCs to include the same URL and headers as GET, as well as to include a POSTDATA section, separated from the headers by two newline characters and terminated by two newline characters, (iirc). The POSTDATA SECTION is specially defined to allow the cliebt to pass parameters to the server.

You coukd try to add a POSTDATA section to your GET requests, but proxies and servers wouldn't interpret it correctly - the two newlines that terminate the GET request headers will be interpreted to terminate the GET request entirely. the following POSTDATA section will be interpreted as a malformed request, and thrown out. You coukd write a custom web server to handle your custom GET format, but that wouldn't fix the ye proxy servers in between, and it wouldn't be used by any existing clients. You could create a custom client to communicate with your server using your custom GET requests, abd this woukd orobably work as long as no proxy servers are in between.

But then you woukd not be communicating over HTTP, but rather a different custom protocol that you invented. And only your software would speak this custom protocol, so you wouldn't gain the interoperability that is typically dssired when using HTTP.

atk
  • 9,244
  • 3
  • 32
  • 32
0

You just need to understand that both method are similar.

You do have the choice to encode the parameter as a query string or in the request body , that is why we have POST or GET.

So when you ask why GET is encoded as a query string does not make sense, because if they are not then they would become POST parameters.

meda
  • 45,103
  • 14
  • 92
  • 122
  • GET and POST are for different tasks as per good REST practices. That's the issue. – Teddy Jun 22 '14 at 16:30
  • but you are asking why GET is encoded in the Url and not in the body like POST? what type of answer are you looking for? – meda Jun 22 '14 at 16:33
  • Why shouldn't get have a body...? Maybe the next version of http standards should allow get to have a body. Is there a good reason why not? – Teddy Jun 22 '14 at 16:40