Re: section 1, intro, for review

Paul Prescod writes:

>> There is a standard for addressing things, the 
>> URI. It works brilliantly. It is the basis 
>> for the most diverse information system in
>> history. It seems odd to me that I now have 
>> to prove that we should continue to promote 
>> its use. 

You don't.  We're in complete agreement on URIs.

>> But I don't see a way to implement the common 
>> address space without GET, and GET leads 
>> naturally to PUT and PUT leads naturally to
>> DELETE and then you need a way to create new 
>> addresses and POST can do that. So HTTP 
>> "falls out" of addressing in my mind. 

This is where we part company.   If what you're addressing is like a 
computer memory, then having an address space implies "GET" and "PUT".  If 
what you're addressing are email users, then I suggest there's at least an 
implication that what follows is not GET, but "Send Mail".   Yes, it's 
handy if a "Get" from an Email address gives you something back, but I 
don't think that's the essence of being able to state my email address as 
a MAILTO: URI.

I am not, not, not, arguing for object oriented APIs as a foundation for 
the web, or even necessarily as good practice for many applications.   I'm 
just suggesting that anything you do that limits or unduly prejudices the 
"operations" you might want to do on on a resource is somewhat at odds 
with the universality of the web.

In  any case, we have absolutely no disagreement on the signifiance and 
importance of URIs.  Thanks!

(So many people have responded to my notes, that in an effort to respond, 
I feel I'm taking too much of the list's attention.  I hope other 
correspondents will take no offense if I don't send further individual 
responses.  I think I've made my points, and I'd rather not contribute to 
an email deluge on this topic.  Many thanks to all who have taken an 
interest, pro or con, in the points that I raised last night.)

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Paul Prescod <paul@prescod.net>
03/18/2002 08:53 PM

 
        To:     noah_mendelsohn@us.ibm.com, www-tag@w3.org
        cc: 
        Subject:        Re: section 1, intro, for review


noah_mendelsohn@us.ibm.com wrote:
> 
> Paul:
> 
> With respect, I think you're reasoning from the converse.  I hear you to
> say:
> 
> * many, many things are well modeled by REST (true)
> * perhaps the very counter-example David gave is a bad one
>   and could be handled by REST (possibly true)
> * lots of folks are out there doing ugly things they shouldn't,
>   including failing to use URI's for addressing, and probably
>   failing to apply REST where it might have advantages
>   (true)

Those are all accurate representations of my position. I am much more
interested in the common address space than in GET/PUT/POST/DELETE
semantics. But I don't see a way to implement the common address space
without GET, and GET leads naturally to PUT and PUT leads naturally to
DELETE and then you need a way to create new addresses and POST can do
that. So HTTP "falls out" of addressing in my mind. But it falls out as
a starting place. I would be happy to see something go beyond HTTP as
long as it doesn't break addressing.

> I don't think that proves that a shared memory (REST) is the right model
> for all the resources we may reasonable want to integrate into the web. 
At
> best it leaves the question open.

There is a standard for addressing things, the URI. It works
brilliantly. It is the basis for the most diverse information system in
history. It seems odd to me that I now have to prove that we should
continue to promote its use. I can't prove that it is sufficient to
address the thought waves of ninja Andromedan space warriors. But it
kind of stands to reason that if nobody has yet run into any limitations
in using URIs to address anything that probably nobody will. I would
like to be able to do a mathematical proof that all of these alternate
address schemes can be implemented in terms of URIs but the problem is
that insofar as their address schemes have no standard there is nothing
for me to do a mapping FROM. All I can say is that I've never heard
about someone who tried it and failed. Billion dollar businesses are
built on URI-addressable information, in every industry.

> ... BUT:  in
> another sense, there's something very different going on with the CDROM.
> The semantically interesting specification for the spinning disk is not
> "load/store", it's "Set speed", "Seek", "Eject", or whatever. Behavior 
is
> encoded in the addresses.    This is very, very different from a world 
of
> shared memories or web documents.
> 
> I think this teaches us that when REST is used to manage memory-like
> resources on the web, we can get by with that one level of description.
> When REST is used for other resources, the higher level semantics are at
> best tunneled through a  Load/Store abstraction.  Sometimes that 
tunneling
> is worth doing, sometimes it's better to admit that the resource is not
> memory-like, and use a protocol more directly appropriate to the 
resource.

That's an assertion that I would need to see backed up by evidence. As
you point out, the CDROM works okay when you address it through the
common interface. When does it become appropriate to invent a special
bus just for the CDROM rather than building on the memory load/store
model? Let's not get too bogged down in the analogy: any abstraction can
get in the way when performance is a central goal. But if it is not,
what's an example of a web service that is not sufficiently
"memory-like" to be amenable to REST. And to get to the issue I am most
interested in, what information exists that should not be addressable by
URI?

>  I think we should at least leave that option open in the web
> architecture.

All I care about is that our "fix" to the web architecture not break the
thing that makes it most powerful, the universal addressability of
information. I'd also like to bring out a point:

> 
> > * lots of folks are out there doing ugly things they shouldn't,
> >   including failing to use URI's for addressing, and probably
> >   failing to apply REST where it might have advantages
> >   (true)

If a technology is uniformly misused, at what point do we start to blame
the technology rather than the technologists? I don't see the experts
using the current raft of web services technologies in a more
sophisticated manner than the denizens of XMethods. I've documented the
problems with the UDDI API. It was probably the first
consortium-described web services API. Can you point me to a few
well-defined, public SOAP/WSDL interfaces that you would claim would not
be amenable to a URI-centric model?

 Paul Prescod

Received on Tuesday, 19 March 2002 15:08:56 UTC