RE: FW: LC Comments: Web Method Feature

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.



Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"Williams, Stuart" <>
Sent by:
07/03/2002 12:27 PM

        To:     "'Mark Baker'" <>, Marc Hadley <>
        cc:     "''" <>, (bcc: Noah 
        Subject:        RE: FW: LC Comments: Web Method Feature

> -----Original Message-----
> From: Mark Baker []
> Sent: 03 July 2002 15:13
> To: Marc Hadley
> Cc: ''
> 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 
> > formulation might be to add an optional "safe" feature instead of the 
> > existing web method feature such that the HTTP binding will use GET 

> > 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]:


     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
</quote> 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 
get their job done?

Developers of binding implementations will know... the binding 
will tell them.

Developers of SOAP applications will know the semantics of the features 
use, because the feature specification will tell them. If the resource 
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) 
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.     



Received on Wednesday, 3 July 2002 14:29:43 UTC