Re: Issue 133, and permitting no body

> Your suggestion is good HTTP, but not good SOAP, IMO.  I think we want an 
> approach that makes good use of both.

Agreed, but I think it could also be seen to be "good SOAP" with a small
tweak to folks' mental model of how SOAP can be used in the context of
web architecture.

> In practice, SOAP bodies are used to convey the "main intent" of a 
> message, with headers used for modifier functions and metadata. 
> Implementations are optimized around this idiom, description languages are 
> tailored for it etc.  In that sense, a SOAP message without a body is a 
> SOAP message without a purpose.

That appears to assume that the only subject of a header can be the
body, no?  Why can't the message itself be the subject?  Many private
SOAP headers I've seen modify the message and not the body, for example
the myriad of transaction identifier extensions, or WS-Routing.

> You would have one or more body entries intended to be used for retrieval 
> operations:
>         <envelope>
>                 <header>
>                         ...your headers here
>                 </header>
>                 <body>
>                         <resourceControl:retrieveResource 
> xmlns:resourceControl="..."/>
>                 </body>
>         </envelope>
> This is good SOAP.  It will be understood and easily generated by a 
> variety of SOAP tools, and there are any number of sensible ways to encode 
> this envelope into a retreival URI.  As with anything of this sort, you 
> would have to publish guidelines on the appropriate use of the binding: 
> break the guidelines and you're likely to get a system that misuses HTTP 
> and/or SOAP. 

Unfortunately, it is counter to web architecture, as GET is the only
method that can mean "retrieve".

I don't wish to dwell on this GET+body thing, but I'd be happy to
continue this discussion if it helps the group understand web
architecture and why using SOAP within it is far from intuitive.

Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.

Received on Friday, 1 February 2002 21:18:14 UTC