21

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?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
  • 1
    Adding items to cart with GET is a bad idea since GET requests are never supposed to have side effects on the server. There are prefetching programs such as FasterFox and Google Web Accelerator that preload content from links on a page by downloading pages in advance. If you're unlucky they might end up adding items to the cart when your user is simply reading a product page. – Martin May 31 '10 at 23:11
  • 1
    @Martin. That make sense. What about ajax wise? Is there a difference if i use GET or POST? Nothing can predict the data i am sending if i have to run through a few javascript functions make the request. –  May 31 '10 at 23:20
  • 1
    Prefetchers should not be a problem for AJAX requests, but I still believe it's a good idea to stick to the correct semantics: GET reqs must not have side effects on the server (i.e. not create, delete or modify anything). If you're merely fetching data (e.g. for an auto-complete box), and the submitted data is small enough to fit in a URL, GET should work fine. Unlike POST responses, GET responses can even be cached, which improves the app's perceived performance. – Martin May 31 '10 at 23:51

5 Answers5

10

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Dan
  • 11,077
  • 20
  • 84
  • 119
  • I looked at that rest page before. It wasnt helpful. i still dont see why i should use over the other except for the 2 differences i mentioned. I dont see why many of my read/write request shouldnt be get (its easier for me...) –  May 31 '10 at 23:02
  • IMHO, understanding REST is the key to answering your question. I added link to another introductory REST article and cited the section where they explain safe and idempotent methods. It is important to understand the underlying web infrastructure (proxies, gateways etc.) will work in accordance with REST (or HTTP spec.). – Dan May 31 '10 at 23:13
7

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

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • if i get /blah.aspx and post to /cmd does /blah change? Also i seen somewhere where the GET was cache even after a post(maybe it was a browser bug? but it didnt seem to matter if the data was GET or POST-ed) –  May 31 '10 at 23:04
  • 1
    The response isn't necessarily the same, there's just no observable side effects from the repeated requests. This page won't always be the same, but me GETting it multiple times won't cause an observable side effect (to me at least, Jeff and Co. May notice a bunch of log hits, etc. But those are relevant to the user) – Mark Brackett May 31 '10 at 23:06
  • Mark Brackett: So it sounds like your saying GET is allowed a prefetch where post is not. But prefetching a form doesnt make sense and right now i am doing it with ajax which also doesnt make sense since it cant predict the javascript input it will need. –  May 31 '10 at 23:13
6

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.

danben
  • 80,905
  • 18
  • 123
  • 145
  • How does intent make a difference? I cant remember where i saw it but i did notice POST data didnt update the page cache so it seems like a get would have done the same thing –  May 31 '10 at 22:57
  • You are referring to specific implementations of clients and servers. Really, they are free to do whatever they want. There is nothing stopping you, functionally, from writing a web server that removes resources on every `GET`, adds resources on every `DELETE`, etc. But you would be angry if you were the client and `GET` were deleting resources, because this is not what we expect is going to happen. That is why intent makes a difference. – danben May 31 '10 at 23:09
  • 1
    Put another way, in OOP you might ask why you should use `getProperty()` only for retrieving a property and `setProperty()` only for setting it, when you could do the reverse just as easily. Having a standard keeps us from being surprised. – danben May 31 '10 at 23:12
  • functionally i could have a javascript enable button to delete a resource. I cant see how a user may not expect what that button would do when its clearly labeled. (but really if it was using ajax they couldnt tell if it was get or post). -edit- 'Having a standard keeps us from being surprised' <-- but this is more for programmers then users? So clientwise it makes no difference? (this question is so hard for me to understand.) –  May 31 '10 at 23:15
  • A PUT request is used to modify not create, where as a POST is meant to create, not modify. It says this directly in the link attached. I would consider updating your post. :) – Mike Hawes Nov 01 '19 at 17:22
1

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

SQLMenace
  • 132,095
  • 25
  • 206
  • 225
0

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.

Mark Brackett
  • 84,552
  • 17
  • 108
  • 152
  • Yes but it isnt in the history and can be retrieved months later (if it still exist). A question is, if i do a get /a it can be cached and if i post /b the results wont be cached but if i visit /a again would i still ise the old data in the cache? does post rest cache on the domain? or does it just say dont cache this specific page? –  May 31 '10 at 23:11
  • @acidzombie-it just says don't cache that request. – Mark Brackett Jun 01 '10 at 00:47