Re: TAG document: SOAP HTTP GET binding available

"Tim Bray" <tbray@textuality.com> writes:
> 
> Here's the problem: the protocols are layered.  Which is to say, you can 
> set up, deploy, and use a Web Service entirely at the SOAP level without 
> going near WSDL.  Lots of people do this all the time.  Given the 
> current POST-only binding of SOAP, such services are not visible in URI 
> space and are thus not good Web citizens.  Dave's proposal is trying to 
> hellp fiix this.  -Tim

You meant that *invocations* of the Web service are not available in
URI space right Tim? That is, what you want is to have the ability
for each stock quote request and for each response, for example, to 
have a URI, right? 

(I'm not disagreeing; just clarifying intent.)

The availability of the Web service itself being in URI space is
solved by having some description of the service in URI space; it
can be in English, Sinhalese or WSDL.

So Sam, what this translates to is basically saying every service
MUST have an HTTP GET binding. Dave's proposal lays out a set of
criteria by which that could be mandated in the SOAP spec. 

To me the idea of mandating an HTTP GET binding is fine and very
useful, but SOAP is totally the wrong place to do it. A better way
for me would be for the TAG to publish a note explaining the value
of having an HTTP GET binding for services (whenever possible, per
the criteria in Dave's note). WS-Desc should be required (as it
is already) to provide a sufficiently rich HTTP GET binding capability
to cover the criteria identified in that note. If someone doesn't 
use WSDL then that's fine, they can still use the binding. (Just 
like how people provide SOAP/HTTP-POST bindings for services without
ever writing them down in WSDL.)

Sanjiva.

Received on Thursday, 9 May 2002 23:05:25 UTC