- From: <noah_mendelsohn@us.ibm.com>
- Date: Fri, 1 Feb 2002 11:08:45 -0500
- To: distobj@acm.org
- Cc: xml-dist-app@w3.org, ylafon@w3.org (Yves Lafon)
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 binding. 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