RE: SOAP breaks HTTP?

Does anybody really doubt that any protocol can be broken?

* SOAP doesn't prescribe any actions other than fault, which we went
through considerable efforts to make sure is relatively consistent with
the HTTP model when used in combination with HTTP. Of all the possible
other actions possible in SOAP, some work fine with HTTP, others don't.
This is in my mind no different than possible actions which may be
defined in HTTP not working well with the HTTP model--even standardized
ones such as the WebDav "depth" header field.

* In general, using SOAP with HTTP is limiting in many ways. Both SOAP
and HTTP bring lots of benefits: Both are based on providing loosely
coupled, extensible frameworks (one with a baked in application, the
other with an emerging set of functionality) but used tied together they
are less powerful. That they can be used in ways that break the Web
model (and each other) is not news to anyone but it seems to come with
the territory when dealing with extensibility.

In short, HTTP can break HTTP, SOAP can break SOAP, and SOAP can break
HTTP if combined in certain ways, but we already know that, right?

Henrik

>> Uh... I had not realized this.  Is one of our SOAP people going
>> to disagree with Roy on this?  It seems like a rather important
>> point.  
>
>I presumably count as a "SOAP person", as a member of the XMLP WG.
>
>I agree that the common use of SOAP breaks HTTP, including far too many
>Web services specifications, but I've worked hard to ensure that SOAP
>1.2 specifically supports a use that does not break it.  That use is
>that the SOAP envelope can be used to carry resource representations.
>Anything else is breaking HTTP, including the RPC use of SOAP.
>
>The major issues are;
>
>http://www.w3.org/2000/xp/Group/xmlp-issues#x12
>http://www.w3.org/2000/xp/Group/xmlp-issues#x192
>
>I wrote about the two different uses last year;
>
>http://www.markbaker.ca/2001/07/SoapUses/

Received on Monday, 25 March 2002 22:21:48 UTC