Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)

Anne Thomas Manes wrote:
> 
>...
> 
> In reference to Paul comments (see below), it's not true that "every bit of
> information on the Web should have a URI address". There's lots of discrete
> information on any random Web page that doesn't have a unique URI.

If the resource is XML, it is addressable through XPointer. If it is in
another syntax then there may be (should be) another query fragment
syntax that can address it.

> ... It is
> true that every Web *resource* has a URI. I view a Web service as a Web
> resource, and hence every Web service should have a URI. (I think we've made
> this association in our Web service definition statement.) If you attempt to
> perform a GET on most Web service URIs, you usually get a WSDL description
> back. Doesn't this qualify as "a clear statement of how to dereference
> addresses to retrieve information"? 

There is nothing in the SOAP specification that requires this
convention. And nevertheless it seems to me to be just a rhetorical
game. I think you know what I mean. In UDDI terms (I know you are
familiar with UDDI), every UDDI binding, business, relatedBusiness,
service, tModel, bindingDetail, businessDetail, businessDetailExt,
serviceDetail and tModelDetail should be URI-addressable in its native
XML. I've discussed this here:

 * http://www.xml.com/pub/a/2002/02/06/rest.html

Nobody has yet demonstrated to me how the current UDDI API is better.
The same goes for the new Google API. In fact this goes for every
deployed SOAP API I've encountered. If SOAP advocates are truly
interested in getting the best technology adopted then at some point
they need to discuss this issue.

> .... More to the point -- how do I specify a
> purchase order (which is a pretty common example of a SOAP input message) in
> a URL? 

When would you submit a purchase order in a safe, side-effect-free
operation?

>...
> If W3C follows a path that defines the "Web architecture" as being equal to
> the REST architecture, it will force the W3C working groups to abandon use
> of SOAP over HTTP POST. This will cause an unacceptable delay in the
> standardization of SOAP. Next we'll find that very few vendors will adopt
> the new standards, and customers will be very happy to use products based on
> SOAP 1.1 and WSDL 1.1. This path will lead W3C into obscurity, and WS-I will
> become the de facto Web services standardization group.

So I guess what you're saying is that any time large software vendors
agree on a spec before they submit it to the W3C, it is the W3C's job to
rubber stamp it rather than slow it down.

 Paul Prescod

Received on Monday, 22 April 2002 19:00:52 UTC