- From: Paul Prescod <paul@prescod.net>
- Date: Tue, 26 Mar 2002 06:58:30 -0800
- To: Christopher Ferris <chris.ferris@sun.com>
- CC: Henrik Frystyk Nielsen <henrikn@microsoft.com>, www-tag@w3.org
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. > 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 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. > ... 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. 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? 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"). 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 10:02:16 UTC