I see where you are coming from. Thank you for your advice. -- -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 9:41 AM, Stephen Groucutt wrote: > 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 > <[email protected]> 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 > > <[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 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2394648
