Re: SOAP breaks HTTP?

Thanks for the request for clarification. I agree that it is important.

Joshua Allen wrote:
> 
>...
> 3) that RPC (assuming that people get confused between SOAP and the
> particular synchronous HTTP binding that people normally use) over HTTP
> is expressly forbidden? (Which, BTW, is completely separate issue from
> SOAP)

How can this be completely separate from SOAP when this binding is
specified in the SOAP specification?

I'm not enough of a language lawyer to say whether it is expressly
forbidden or not. The HTTP specification describes the semantics of
different methods. In my experience, semantics cannot be checked by
software, only wetware, so an express injunction would not have many
teeth.

> 4) that RPC over HTTP violates someone's opinions about how web systems
> SHOULD be developed (which BTW I tend to agree with, so no need to
> preach to the converted on this particular design preference)

Yes, but I would put it somewhat stronger: RPC over HTTP breaks
architectural principles of the Web that were first described in 1996.
http://www.w3.org/DesignIssues/Axioms.html#state

> 5) that SOAP breaks when used over HTTP that has intermediaries?

I would say that the SOAP RPC binding disables those intermediaries by
hiding HTTP conventions in SOAP ones. The two most obvious examples are 

 a) firewalls, which might like to filter RPC out by default but cannot
without special knowledge that SOAP RPC is not vanilla HTTP. 

   http://www.counterpane.com/crypto-gram-0006.html#SOAP

 b) caching proxies, which might like to cache repeatable GET results
but cannot without special knowledge of which SOAP methods in a
particular RPC interface are cachable.

I would add one more thing:

6) SOAP adds features to HTTP but it is not clear how to use those
features AND use HTTP methods with their appropriate semantics. For
instance how can I use SOAP headers to do routing or signing in a
GET/PUT/DELETE?

 Paul Prescod

Received on Monday, 25 March 2002 21:07:54 UTC