tags:

views:

118

answers:

6

I know you dont 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 dont understand the benefits of one over the other. I do notice post doesnt 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?

+5  A: 

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
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
acidzombie24
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
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
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.)
acidzombie24
+1  A: 

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

SQLMenace
+1  A: 

Here is the answer:

Why use POST rather than GET in data collection?

Sarfraz
+5  A: 

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

BalusC
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)
acidzombie24
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
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.
acidzombie24
+1  A: 
Dan
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...)
acidzombie24
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
A: 

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. Its safe to bookmark and refresh gets, so theres 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
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?
acidzombie24
@acidzombie-it just says don't cache that request.
Mark Brackett