Re: SOAP breaks HTTP?

Paul,

I think Henrik's point is valid. A developer can abuse
HTTP without introducing SOAP or SOAP RPC. That doesn't
invalidate the HTTP spec, just the developers interpretation
of it (if they even read the RFC, which I seriously doubt!).

The fact is that the HTTP binding in the SOAP Part 2 spec[2]
is but one in the set of possible bindings to
HTTP. It is NOT exclusive. There was much discussion of
use of URI encoding of SOAP requests for use with HTTP
GET, but the WG didn't and likely won't go there this
time round.

That doesn't mean that a more complete and "restful" binding
can't or won't be developed by someone at some point in the
future.

To quote the SOAP 1.2 Part 2 spec directly, from section
7 SOAP HTTP Binding:

	The purpose of the SOAP HTTP Binding is to provide a binding of
	SOAP to HTTP. It is important to note that use of the SOAP HTTP
	Binding is optional and that nothing precludes the specification
	of different bindings to other protocols, or indeed to define
	other bindings to HTTP. Because of the optionality of using the
	SOAP HTTP Binding, it is NOT a requirement to implement it as
	part of a SOAP node. A node that does correctly and completely
	implement the HTTP binding me to be said to "conform to the SOAP 	1.2 HTTP 
binding."

Cheers,

Chris

Paul Prescod wrote:

> Henrik Frystyk Nielsen wrote:
> 
>>...
>>
>>* 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.
>>
> 
> Here's my gripe. I've never seen a single SOAP web service used on HTTP
> that did not violate 
> 
> a) the semantics defined in the HTTP specification and/or 
> 
> b) the idea that all web resources should be addressable through a URI.
> 
> I've documented in detail, for example, how the UDDI SOAP service
> violates these principles:
> 
>  * http://www.xml.com/pub/a/2002/02/06/rest.html?page=2
> 
> I've discussed how some other random services from XMethods do the same:
> 
>  * http://lists.w3.org/Archives/Public/www-tag/2002Mar/0080.html
> 
> Can you point me to a public, running SOAP-based web service that does
> *not* take information that rightfully would have URIs and be "in the
> Web information space" and put that information behind a method-based
> interface with no addressability?
> 
>  Paul Prescod
> 
> 
>

Received on Tuesday, 26 March 2002 08:19:32 UTC