I'm not sure I get where you're coming from exactly. It matters very much how data is sent to the server, as part of the uniform interface is the expected server behavior for each HTTP verb.
If I issue: GET /my/resource/12345 Accept: text/html ... Then I expect to receive resource 12345 in HTML format (or some HTTP error code that explains why I cannot). If I issue: POST /my/resource .... with some entity body of a type described by the Content-Type header, I expect a Created response with a Location field pointing to the new resource (or some HTTP error code that explains why the resource could not be created). I would not expect a GET issued with an entity body to do anything useful with that entity body, nor would I expect a POST issued with no body to create anything useful, unless the resource was of a certain type that required no input data to be created. These assumptions allow me, as a consumer of that RESTful resource, to interact with that resource without having to do anything special. You can, of course, define a resource that ignores these conventions and does its own thing. You'll just lose the benefit of offering a uniform interface to consumers of that resource - and when you start needing clients to do custom, non-standard things, you're one step closer to the old WSDL/SOAP thing. On Mon, Sep 14, 2009 at 9:44 AM, Schley Andrew Kutz <sak...@gmail.com>wrote: > 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 > > <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<http://www.cs.tut.fi/%7Ejkorpela/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 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394646
