- From: <noah_mendelsohn@us.ibm.com>
- Date: Wed, 3 Jul 2002 14:02:00 -0400
- To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
- Cc: "'Mark Baker'" <distobj@acm.org>, Marc Hadley <marc.hadley@sun.com>, "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>, xml-dist-app-request@w3.org
Stuart Williams writes: >> Mandating its use (needlessly IMO) denies the >> messaging/tunneling view. I don't think so. All the admonitions to use GET vs. POST are SHOULDs. Therefore a "tunnelist" can blindly use POST and get on with it, as he or she always has. Well, you might say (I infer somewhat presumptuously), why should a "tunnelist" even have to think about something so disorienting as a feature having to do with HTTP and REST. To which I would answer: * Because to use a binding such as HTTP you need to learn to use the API documented for that binding. That API happens to have a property which essentially is documented as "set this to GET if your a chameleon who knows what you're doing and you care, otherwise use POST." So, not caring, you use POST. * All of the properties are abstractions anyway. None of this requires a typical user to bother or not bother with anything. If you are building an implementation that's intended for use only by tunnelists, nothing here requires you to surface the choice to your users. Surely you had to set the method to POST in the actual HTTP transmission in any case no matter what architecture we chose, and that's all you have to do now. In other words, existing SOAP HTTP implementations are already more or less compatible with the new binding, they just don't offer a level of control over WebMethod that a chameleon should want. Cheers. Noah ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ "Williams, Stuart" <skw@hplb.hpl.hp.com> Sent by: xml-dist-app-request@w3.org 07/03/2002 12:27 PM To: "'Mark Baker'" <distobj@acm.org>, Marc Hadley <marc.hadley@sun.com> cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: RE: FW: LC Comments: Web Method Feature > -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: 03 July 2002 15:13 > To: Marc Hadley > Cc: 'xml-dist-app@w3.org' > Subject: Re: FW: LC Comments: Web Method Feature > > > > Marc, > > I think my response to Stuart should answer your first question. > > On Wed, Jul 03, 2002 at 01:24:54PM +0100, Marc Hadley wrote: > > All good questions. I don't think the MEP and web method feature (as > > currently formulated) are particularly orthogonal. I wonder if a better > > formulation might be to add an optional "safe" feature instead of the > > existing web method feature such that the HTTP binding will use GET only > > when the MEP is response and the "safe" feature is set ? > > While GET is safe, not all safe methods are GET. For example, HEAD is > safe. From [1]: <quote> Axiom In HTTP, GET must not have side effects. The introduction of any other method apart from GET which has no side effects is also incorrect, because the results of such an operation effectively form a separate address space, which violates the universality. </quote> ...care to comment? > I have to admit to being confused by the suggestions to derive the > method. Why is that desirable? Well we continue to have the two views... the chameleon view and the messaging/tunneling view. We are close to a position that admits both views. The Web Method features enables the chameleon to take on the REST resource state manipulation and retrieval view. Mandating its use (needlessly IMO) denies the messaging/tunneling view. > A developer has to know what methods are being invoked. How else can they get their job done? Developers of binding implementations will know... the binding specification will tell them. Developers of SOAP applications will know the semantics of the features they use, because the feature specification will tell them. If the resource state view is important to them, they will use the Web Method feature. If they think more in terms of message exchange (in a binding agnostic fashion) Web Method is unlikely to be a feature they will use. Developers of Soup to Nuts homogeneous implementations will likely streamline their implementations based on their understanding of the agregate behaviour of their application and the features and bindings it actually uses. > > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@acm.org > http://www.markbaker.ca http://www.idokorro.com Cheers, Stuart [1] http://www.w3.org/DesignIssues/Axioms.html#state
Received on Wednesday, 3 July 2002 14:29:43 UTC