Re: Issue 133: SOAP and Web Architecture: Draft sentences for HTTP bi nding preamble.

"Williams, Stuart" wrote:
> 
>...
> 
> 
> 7.1 Introduction
> 
> This SOAP binding specification adheres to the SOAP Binding Framework (see
> SOAP Transport Binding Framework), and as such uses abstract properties as a
> descriptive tool for defining the functionality of certain features.
> </draft>
> 
> Comments? Flames? etc.

I think Mark Baker is on vacation. I don't have time to go through all
of the discussions again but I do not think it is sufficient and I doubt
he would. 

> It is also possible to use
> the HTTP binding specified here in a way that preserves the semantics of the
> HTTP POST method [ref RFC2616], however the onus to ensure the preservation
> of HTTP POST semantics falls upon the SOAP application developer.

Of course you could define one particular method that preserves the
semantics of POST. But how could you define a service that did so when
the binding provides no way to use another method when POST is
inappropriate, for instance for safe, idempotent information retrieval
or deletion? The use of POST for this is an abuse:

"In HTTP, anything which does not have side-effects must use GET"

 * http://www.w3.org/DesignIssues/Axioms.html#state

Although Tim has agreed that this is stated a little bit too strongly
the general approach is correct and the reasons for it are rock-solid
and are the foundations of the Web. It is great that you allow multiple
bindings but the default binding must respect the axioms of web
architecture. A SOAP call that does a safe and idempotent information
retrieval should use GET and express the thing that is being gotten
through the URI. SOAP should have a built-in feature that allows this.

 Paul Prescod

Received on Tuesday, 19 February 2002 04:35:51 UTC