Re: FW: LC Comments: Web Method Feature

On Wed, Jul 03, 2002 at 05:27:02PM +0100, Williams, Stuart wrote:
> >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?

Yes, Tim needs to focus on the issue, not a symptom of it. 8-)

See http://lists.w3.org/Archives/Public/www-tag/2002Jan/0075

> > 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. 

Where did "messaging" come from there?  I think the chameleon view is
as much about messaging as the tunneling view ... at least as far as
the underlying protocol permits.

> 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.

For HTTP, yes it does, more or less.  It encourages SOAP implementations
to expose the method in some manner to developers, thereby breaking the
notion of SOAP as a layer when bound to HTTP.  This is a good thing IMO.
As you know, I've been saying that SOAP isn't a layer (with HTTP) for
some time.

If developers want to use the tunnelling approach, they can use TCP.
That's the right thing to do on many levels, IMO.

> > 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.

But you need more than features to use an application protocol, you need
application semantics.  Are you suggesting that they be exposed as
features?

> 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.

If the resource state view is not important to them, why are they using
HTTP?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 3 July 2002 13:24:14 UTC