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

Anne Thomas Manes wrote:
> 
>...
> 
> Not all Web resources are XML. Are you now attempting to specify that the
> Web architecture requires that all Web content by available and accessible
> as XML?

We're getting off into a diversion. Can we agree that every piece of
information available on the Web should be URL addressable or a PART of
a URL-addressable resource? And I don't mean part in a vague sense: I
mean you download a representation and the piece of information is in
there. In many content-types you can also directly link to
"sub-resources" of the resource (e.g. XML, PowerPoint, PDF)

>....
> 
> Perhaps, but we can certainly establish this convention as the norm or
> required. Many SOAP implementations adhere to this convention already. I
> don't view this as a requirement of the SOAP spec, but as a requirement of
> the Web services architecture.

Okay, for the sake of argument I'll concede this point because the
important issue is the one above.

>...
> 
> I've never made the claim that the current UDDI API is better than other
> approaches. (I can think of many better mechanisms to perform discovery.)

No, I'm not talking about better ways to perform discovery. I'm talking
about better ways to express the *existing API*. i.e. we can improve it
with *no new ideas* just by recasting it in terms of URIs. Same for
Google. Same for any other SOAP API you can mention. If you care about
technology then it should worry you that less flexible and powerful
services are being unleashed on the world just to be "SOAP compliant".

>...
> > > .... 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?
> 
> I don't think you get the point. People want to submit a Purchase Order over
> the Web, and they aren't overly concerned with whether or not it's done
> using a "safe, side-effect-free operation", they just want to submit the PO.
> What's the best way to do it? I don't think it's appropriate to do it via
> GET. You might be able to do it via PUT, but you aren't trying to publish
> the PO, only submit it. POST seems like the safest, side-effect-free
> approach.

That's exactly my point. POST is the perfect method for this. We *all
agree* that GET should NOT be used for submitting a Purchase Order. The
heart of the REST+SOAP view is that SOAP users should use the right HTTP
method for the type of thing they are doing. GET sometimes. POST
sometimes. PUT sometimes. DELETE sometimes. (but GET and POST as a bare
minimum!)

>...
> My suggestion is that W3C explore REST in a separate working group. 

Forget REST. Concentrate on Web architecture. One of the principles is
that as many things as reasonably possible should have URIs:

"The essential process in webizing is to take a system which is designed
as a closed world, and then ask what happens when it is considered as
part of an open world. Practically, this effect on a computer language
is to replace the names/tokens/identifiers for URIs. Thus, where before
reference could only be made to something in the same
document/program/module one can with equal ease make reference to
something in a different one somewhere in that abstract space which is
the Web."

 * http://www.w3.org/DesignIssues/Webize.html

If you have a non-REST or non-HTTP way to weave this into SOAP then I
would probably be satisified with that. Either way, I need SOAP to
support "webizing" systems. I think this falls directly out of the
group's mandate:

"The Web can grow significantly in power and scope if it is extended to
support communication between applications, from one program to another.
The purpose of this Working Group is to create a simple foundation to
support the needs of such communicating applications."

To me, if you don't support web-izing systems then you have NOT
significantly improved the power and scope of the Web. Furthermore, this
is not an issue being raised late into the process. It has been raised
repeatedly throughout the process.

 Paul Prescod

Received on Tuesday, 23 April 2002 01:21:11 UTC