Why should I POST data rather than GET?

问题:

I know you don't want to POST a form with a username and password where anyone could use the history to see or situations where repeat actions may not be desired (refreshing a page = adding an item to a cart may not be desired). So I have an understanding when I may want to use one over the other. But I could always have the server redirect the URL after a GET to get around the cart problem and maybe most of my forms will work perfectly fine with GET.

Why should I use POST over GET? I don't understand the benefits of one over the other. I do notice POST doesn't add data to the history/URL and will warn you about refreshing the page, but those are the only two differences I know of. Why as a developer might I want to use one over the other?

回答1:

Every HTTP method: POST, GET, PUT, DELETE, etc. caries its own semantics. When choosing the right method it is important to understand the HTTP and REST, since it is the way HTTP was meant to work and the way underlying network infrastructure operates.

A good tutorial on REST is available here. Here is what is says about POST and GET methods:

• Because the same interface is used for every resource, you can rely on being able to retrieve a representation — i.e., some rendering of it — using GET. Because GET’s semantics are defined in the specification, you can be sure that you have no obligations when you call it — this is why the method is called “safe”. GET supports very efficient and sophisticated caching, so in many cases, you don’t even have to send a request to the server. You can also be sure that a GET is idempotent — if you issue a GET request and don’t get a result, you might not know whether your request never reached its destination or the response got lost on its way back to you.

  The idempotence guarantee means you can simply issue the request again. Idempotence is also guaranteed for PUT (which basically means “update this resource with this data, or create it at this URI if it’s not there already”) and for DELETE (which you can simply try again and again until you get a result — deleting something that’s not there is not a problem). POST, which usually means “create a new resource”, can also be used to invoke arbitrary processing and thus is neither safe nor idempotent.

回答2:

All of the data in a GET request is carried in the URL, which has a size limitation and is also visible to the user. A POST request allows you to send a payload as well.

In addition to the technical differences, there is the matter of the intent. The HTTP standard describes the ways that the different requests (GET, POST, PUT, DELETE, HEAD) are intended to be used; for example, PUT is intended to add a resource, DELETE is intended to remove one, and POST is intended to modify one. Could you use a GET request instead of a PUT or DELETE? Sure, but following standards makes intent explicit.

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html for more info.

回答3:

If you want an idempotent request URI (i.e. response is always the same), then use GET, else POST.

回答4:

Among other things, GET is limited to 2K (some browsers will accept more) and it is visible in the URL

回答5:

GET and POST have semantic meaning - GET is used to retrieve a resource and POST is used to modify it. The semantics are why you notice the implementation differences in your web browser - since POST allegedly modifies data, a browser should warn before resubmitting a POST request/command.

The entirety of the web goes on those semantics. It's safe to cache a GET request, but not a POST command - so that's what caching proxies do. It's safe to GET a resource multiple times, so you have link pre fetchers that do just that. It's safe to bookmark and refresh GETs, so there's no warning from browsers, etc., etc.

That said, there is no security difference - so the username password example you give isn't exactly accurate. POST is as easily tampered with or viewed as GET.