CODEWITHSUNDEEP
httppostparametersget
NubbleWumps
NubbleWumps

Reputation: 33

Why do HTTP GET and POST requests pass parameters to the server in different ways (body vs. URI)?

I know that typically, GET requests pass relevant parameters by appending query strings to the URI. POST requests pass parameters by inserting them into the request body.

I also know that it is considered bad practice to pass GET parameters into the request body, but that is not an explanation as to why this behavior was initially implemented. As far as I can tell, the main difference between GET and POST requests is more or less semantic. That is, I can generally assume GET is safe and POST is not, which helps me understand that I can cache GET results, and allow GET to call multiple times without worrying that I am going to mess something up server-side. This does not explain why there is a different implementation for passing parameters. Would it have been a bad idea to have GET be semantically equivalent to the way that it is used now but use the request body to pass parameters instead of the URI? Similarly, was there a compelling historical reason for the designers of HTTP to divide how GET and POST stored parameters (in such a seemingly arbitrary way)?

Upvotes: 0

Views: 871

Answers (2)

Evert
Evert

Reputation: 99581

I think it might help to re frame this a bit to not look at these as parameters, but take a step back.

Ultimately the purpose of the GET request is to ask a server for the representation of a given URI. The fact that the URI has things that are 'parameters' or 'variable' is kind of irrelevant here.

The idea of the GET request is, give me the thing at this URI. The fact that there are some mechanisms to dynamically build up these URIs is not important.

You can do the exact same thing with POST. Any URI that you can GET, you could send a POST request to. So these URI variables can also exist for POST.

So on a high level, this is what the requests are for:

GET - Return the representation at the given URI
PUT - Replace the representation at the given URI
DELETE - Remove the resource at the given URI

Looking at these operations as something you do at the given URI it starts to make sense that GET doesn't have a request body. If the purpose of the request is simply 'give me the thing at this uri', there's no real reason to also have a body.

Likewise, it doesn't make that much sense for a PUT request to respond with a body. The purpose of PUT is to replace whatever is at the given URI with the request body. The caller only really needs to know if the operation succeeded or not, so a HTTP status code is enough.

For DELETE neither the request or response body really makes sense. All you need to know is there is a URI, and you are calling the DELETE operation, which succeeds or fails.

So what about POST? POST is really a bit of a catch-all that is used for basically 'anything else'. You're not explicitly replacing, removing or retrieving a resource, but rather you are doing 'some arbitrary operation', like doing an RPC call or creating a new resource in a collection.

Unlike GET, PUT, and DELETE, the meaning of POST is much more loose.

POST - Do an arbitrary operation at the given URI.

Upvotes: 1

Quentin
Quentin

Reputation: 943630

Data in the URL can be linked to, bookmarked and easily shared.

Data in the request body can be big, and easily include things which are not text (like file attachments).

Upvotes: 1

Related Questions