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 <sak...@gmail.com> 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
