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

All,

Sorry that I've taken so long to reply to this thread.

Going back to the beginning, I concur with Dave that the issue of GET/POST
in Web services has nothing to do with safe and unsafe.

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. 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"? I believe that SOAP supports both of the
requirements that Paul stated to qualify as a Web protocol.

In reference to Mike and Nigel's comments regarding SOAP caching, I have to
side with Don Box. I'd much rather buy a new SOAP-aware Web services
router/cacher than force my users to express sensitive application
information in a URL. (What if I need to encrypt the data that I'm sending
to the service?) See also Mark Nottingham's comments on the viability of Web
service caching based on REST. 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? If you view SOAP as only an RPC, then you're ignoring a significant
use of SOAP.

Some may view the mis-use of POST as morally wrong, but as a group
representing its members, W3C needs to accomodate the wishes of its members.
Mark Baker is way off base when he said that RPC "has repeatedly
demonstrated its inability to be deployed on the Internet". SOAP RPC is
being used quite successfully right now. My customers could care less
whether SOAP over HTTP POST is conforment with what some are now trying to
define as "the Web architecture". They just want something that works, and
SOAP over HTTP POST works.

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.

It's not that I don't think REST is interesting, it's just that the REST
architecture and the current Web Services architecture (based on SOAP 1.1)
are fundamentally different, and we can't attempt to force such a
significant change on technology that's being successfully used today.

I think it's a great idea to develop a new model for Web services based on
the REST architecture (although we may want to call them REST services or
something else). Just don't let REST interfere with the release of SOAP 1.2
and WSDL v.next.

Respectfully,

Anne Thomas Manes
CTO, Systinet

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Tuesday, April 16, 2002 6:03 AM
> To: David Orchard
> Cc: www-ws-arch@w3.org; xml-dist-app@w3.org; www-tag@w3.org
> Subject: Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)
>
>
> David Orchard wrote:
> >
> >...
> >
> > My belief is that the web has been based upon a shared
> information space,
> > primarily through use of GET/POST methods.  However, as we move
> towards more
> > machine to machine oriented communications, with arbitrary
> payloads of XML,
> > and it's focus on update/service oriented architectures, the need for a
> > public contract for safe actions is dramatically reduced.  ...
>
> I disagree with your statement of the issue. It isn't about a public
> contract for safe operations, it is about addressability. Given:
>
>  1 every bit of information on the Web should have a URI address
>
>  2 given an address, a client must be able to derference it to get a
> representation of the information item.
>
> This implies to me that every "web protocol" that exposes information
> needs
>
>  a) an addressing mechanism and
>
>  b) a clear statement of how to dereference addresses to retrieve
> information.
>
> If you invented a soap:// addressing mechanism, then the need for
> SOAP-on-GET would be greatly reduced. But until SOAP has a) and b), I
> don't see how it can be any more a "Web protocol" than DHCP or POP is.
>
>  Paul Prescod
>

Received on Monday, 22 April 2002 18:23:09 UTC