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 04:19:01 UTC