Re: SOAP breaks HTTP?

Paul,

Please see below.

Cheers,

Chris

[1] http://www.w3.org/2000/09/XML-Protocol-Charter#outofscope
[2] http://www.w3.org/2000/09/XML-Protocol-Charter#scope

Paul Prescod wrote:

> Christopher Ferris wrote:
> 
>>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!).
>>
> 
> I get this argument often. I'll try to paraphrase it and you can correct
> me if I misunderstand: "HTTP can be abused and often is. Therefore we
> should introduce a specification that not only is likely to encourage
> the abuse of HTTP, but darn near requires it." This makes no sense to
> me.


Nonsense. This is pure sophism.


> 
> 
>>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. 
>>
> 
> Here's another mysterious, but common argument. "We've provided a broken
> way for you to use SOAP with HTTP. But if you're industrious enough you


With all due respect, you haven't demonstrated that the binding
itself is "broken". While it may not leverage the full set of
HTTP methods, that doesn't necessarily lead to "it is broken".


> can go off and invent ways that actually work with HTTP as it was
> designed. Good luck!" If it were easy to make SOAP fit the web

> architecture you would have just done it, right? So it is very
> unrealistic to think that anybody other than Mark Baker will ever make a
> SOAP web service that supports web architecture rather than fighting
> against it.


I don't believe for a minute that anyone is "fighting against"
web architecture.

> 
> 
>>... 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.
>>
> 
> I personally do not believe that compatibility with web architecture is
> something you delay to version 2 of a W3C specification.


Putting "compatibility with web architecture" aside, the issue
is actually one of charter and scope[1]. Defining a "compact encoding"
such as URI encoding of a SOAP message is expressly out of scope
for the XMLP WG as originaly chartered.

> 
> And anyhow, we all seem to agree that there is something fishy about the
> SOAP/HTTP RPC binding. Does anybody want to stand up and defend it? If
> not, then what is it doing in the spec?


It is in the XMLP WG charter[2] to provide:

"A convention for the content of the envelope when used for RPC (Remote 
Procedure Call) applications."

The WG has explicitly placed this in the Part 2: Adjuncts spec
because this is but one possible use of SOAP with the hopes
(IMO) to de-emphasize the current perception that "SOAP is RPC".

> 
> Even Don Box has recently been spotted publicly questioning the
> scalability of RPC[1][2]. Let's just excise it and some day, create a
> SOAP/HTTP binding when we can figure out how to do it in a way that
> respects both web architecture ("everything has a URI") and HTTP ("use
> GET to get").


I don't think that this is an option at this point.


> 
> Yes, I know the history, but we're talking about the *first* W3C version
> of this specification, right? Why should the W3C be bound by the history
> of the specification when it was run by Microsoft, IBM and others in the
> smoke-filled room. What does that say about the W3C process if large
> companies can design a technology, hold it at arms length until it gets
> some uptake and then hand it over to the W3C and say: "You'd better not
> change this much, it's already widely implemented." Who is in the
> driver's seat?
> 
>  Paul Prescod
> 
> [1]
> http://www.razorsoft.net/weblog/stories/2002/02/28/thatKeynoteyouKnowTheOne.html
> [2] http://groups.yahoo.com/group/rest-discuss/message/827
> 
>

Received on Tuesday, 26 March 2002 12:32:11 UTC