[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What does SOAP really add?
Hi Jim, Jim said: > POST brings more side effects because it is designed to have side effects, > while GET is supposed to be safe. Quoting from section 9.1.1 of RFC 2616 [1]: > > "In particular, the convention has been established that the GET and HEAD > methods SHOULD NOT have the significance of taking an action other than > retrieval. These methods ought to be considered "safe". This allows user agents > to represent other methods, such as POST, PUT and DELETE, in a special way, so > that the user is made aware of the fact that a possibly unsafe action is being > requested. Didier replies: Off course, what is changing all this are the server side scripts and several issues like: a) the fact that an HTTP GET can include parameters in the URI. The document associated with the URI can be a script and thus create side effects. b) The fact that actual servers include the capability to overide any HTTP method Jim said: > > Naturally, it is not possible to ensure that the server does not generate > side-effects as a result of performing a GET request; in fact, some dynamic > resources consider that a feature. The important distinction here is that the > user did not request the side-effects, so therefore cannot be held accountable > for them." > > Note that we are talking about side effects on the server, not any effect the > document() function would have on the output of the XSLT tranformation. > > > Off course, when used in the context of the "document" function (or > > anything else having the same intent: fetching an XML document). The basic > > goal of any construct like the "document" function is to fetch an XML > > document. Didier replies: yes Jim said: > > But POST is not intended for fetching documents. That is what GET is for. From > section 9.5 of the RFC [2]: > > "POST is designed to allow a uniform method to cover the following functions: > > - Annotation of existing resources; > > - Posting a message to a bulletin board, newsgroup, mailing list, > or similar group of articles; > > - Providing a block of data, such as the result of submitting a > form, to a data-handling process; > > - Extending a database through an append operation." > > Of course this is one of the REST proponents' objections to SOAP--if you want > to fetch a document using the SOAP HTTP binding you must use an HTTP POST, > which violates the semantics specified in the HTTP spec. Didier replies: I agree that using SOAP to fetch a document is not the best method and all my posts reflect this point of view. We can say that independently of the HTTP method (either POST or GET), the simple fact that at the side a script process the method may lead to side effects. Simply because the method is used as an implicit function call. So, I guess that we should enforce the difference between document fetching and function call but that would contradict the actual practice of thousands if not millions of developers. We have more and more to face the web legacy and actual practices in our thinking. cheers Didier PH Martin
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|