Re: Issue 133, and permitting no body

Yves Lafon writes:

>> Well, having the envelope sent as a parameter is OK.

That's exactly what I have in mind.  Of course, there are ways to misuse 
anything.  The SOAP bindings should come with instructions that say:  If 
you're doing a (possibly parameterized) retrieval on a resource, here is 
the right way to use SOAP in conjunction with the binding that does a GET 
with the SOAP envelope encoded in the URI parameter.   If you're doing 
something else, then to use HTTP properly, you should use another SOAP 

I see SOAP in these contexts as being very much like well-structured CGI 
or servlet programming.  If you use it with good taste, then you can 
leverage the web architecture, and benefit from the power and 
interoperability that SOAP provides (common tooling, etc.)  As with CGI, 
there are lots of ways to misuse soap, and there will be lots of ways to 
misuse even an otherwise sensible HTTP binding. 

I still don't see why leaving the SOAP architecture exactly as it is, SOAP 
body and all, and then binding to an appropriate use of URI's and HTTP 
GET, isn't the best way to both be architecturally clean and to promote 
interoperability at the SOAP level.  A SOAP message without a body seems 
to me to be a SOAP message that doesn't do anything, but carries in its 
headers lots of modifiers that would have applied if you were doing 
anything.  Maybe I'm missing something, but that doesn't make sense to me.

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

Received on Friday, 1 February 2002 11:22:30 UTC