Dave, Thank you for your input; it is much appreciated. I'm just bothered by the fact that GET and POST have a data delivery mechanism tied to them in addition to their semantic purpose of immutable and modifiable actions. It would seem to me that the method by which you send data to the server should not dictate what the server does to that data.
-- -a "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Einstein On Sep 14, 2009, at 3:22 AM, David Bordoley wrote: > Hi Andrew, > > It might be more useful if you could supply a more detailed example > that is causing you headaches. Really the difference between POST and > GET is idempotence. GET operations must be idempotent, not having side > effects, while POST operations may have side effects as defined by the > server. A good rule of thumb is that if a request returns data but > doesn't change the state of the server, than GET should be used as it > allows for sane client/intermediary caching. > > On Sat, Sep 12, 2009 at 12:21 PM, Schley Andrew Kutz > <[email protected]> wrote: >> I'm faced with a dilemma. I'm trying to be a good RFC consumer and >> stick with the true purpose of GET and POST (see >> http://www.cs.tut.fi/~jkorpela/forms/methods.html >> for a good discussion on the history of these two HTTP verbs). >> Plainly put, GET is for retrieving data and POST is for creating >> data. >> However, the problem lies in the fact that their purpose and their >> data encoding mechanism are mutually exclusive. GET requests encode >> data in the URL and POST requests encode data into the form. However, >> it is not always desirable to issue a GET request with URL-encoded >> data (login information for example), not is it always desirable to >> POST data with a form (sometimes a query string will do). > > I actually disagree with this statement. Using GET to pass login > parameters is fine, and in some cases preferable (particularly as it > relates to client caching). If you're concerned about security, you > should encrypt such requests using SSL (you really should do this > regardless of the method used in this case). > > Also the URI RFC doesn't require that URI parameters be form encoded. > You could as easily pass JSON, XML, etc. in the query string as long > as it is properly escaped. Form encoding for these parameters is > typically chosen as a pragmatic decision due to HTML. > > Dave > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394479 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394618
