RE: section 1, intro, for review

Roy,

I'd like to understand your rant a bit more.  This shouldn't be interpreted
as agreement, just me seeking understanding.  I think you are saying that if
people want to create object-specific interfaces using URIs, XML, HTTP, then
they shouldn't call it anything to do with the web.  More like "XML Internet
Services" or something like that.  That the notion of a shared information
space with well-defined interfaces is core to the web.  Not usage of URIs,
HTTP, Markup.  Those are helpful and interesting and good practice and ....
but not core to the web.

Further, attempts to put object interfaces onto the web - like
CORBA/DCOM/RMI - failed because they didn't use well-defined interfaces.
Their "failure" has nothing to do with complexity, lack of implementations,
too early to market, binary formats, bootstrap problems, no buy-in across a
big enough community or other issues.  I think that this implies that if
CORBA/DCOM/RMI had used HTTP PUT/POST/DELETE/GET in a RESTful style, they
would have had a much better chance of success.  You said this was the
lesson to learn from their failures.

Expressed a different way, the web succeeded because it was loosely coupled.
The use of well defined interfaces is the essensial element in this loose
coupling.  The use of well-defined interfaces allows clients and servers to
communicate without knowing the specifics of the resource.  Putting an
object interface onto a URI effectively tightly couples the sender/reciever
in a way that should never be considered part of the web.  The problem with
a non well-defined interface is that the client now has to discover the
interface (or whether it's changed) and create/change the sending messages.
With well-defined interfaces, the components can talk to each other without
this discovery/interface compilation step, which will scale/adapt/perform/be
more reliable, etc.

Does this roughly match what you are saying?

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Roy T. Fielding
> Sent: Monday, March 18, 2002 10:49 PM
> To: noah_mendelsohn@us.ibm.com
> Cc: Paul Prescod; www-tag@w3.org
> Subject: Re: section 1, intro, for review
>
>
> This response is in general to the discussion, even though I
> only reference
> one prior message.
>
> > 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.
>
> I am unclear as to where you got the idea that REST is a
> shared memory.
> It defines an architectural style for building applications in which
> components interoperate via a standardized interface.  What is on the
> other side of that interface is unconstrained.
>
> > Furthermore, I think we need to admit that even when REST
> is applied,
> > there are two different sorts of cases.  I would compare these to
> > Load/Store into the memory of a computer, and Load/Store
> into the I/O
> > space.
> >
> > I can generally store into the memory of a computer, or
> into the memory of
> > the web (e.g. PUTing an html document)  I can then do a
> load (Get) from
> > the same address (URI) and retrieve what I put in.
> There's not much else
> > to say about it.  A pure memory.
>
> Do you honestly think that the Web is so limited?  How do you
> account for
> the web-based control interfaces in routers, refrigerators,
> air conditioning,
> etc.  They exist already.  Check out your nearest IBM
> innovation center.
>
> > An I/O bus is trickier.  At one level, it looks like the memory:
> > Load/Store.   However, if I store into the right location
> in the I/O
> > space, magic happens.  The CD ROM drive spins faster.
> Maybe if I load
> > from the same location I get back in indicator of the new
> speed, or maybe
> > not.  Modeling the disk controller as load/store, I get to
> use lots of
> > hardware and software mechanisms that are common with the
> real memory
> > example.  That's why we try to use REST where we reasonably
> can on the
> > web;  common abstractions, shared implementation
> mechanisms, and to some
> > degree we can reason about the persistent state of the web.
>  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.
>
> No, it is all just content.  It is possible to define systems
> using either
> data integration or control integration, but usually there is some
> combination of both.  REST simply limits the control integration to
> common semantics for all resources.  It is up to the
> application developer
> to lay out their resource space such that it matches the intuitive
> controls of a CD ROM (or whatever) and to match that with
> standard data
> forms that can be understood when exchanged.  It usually takes folks a
> few tries before they get it right (information design is hard).
>
> Applying REST does not result an ideal interface for all
> forms of behavior.
> It simply results in a common interface that is very flexible
> and very close
> to ideal for one common form of behavior.
>
> > 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.
> >  I think we should at least leave that option open in the web
> > architecture.
>
> I don't.  The reason we have a Web architecture is the same
> reason that we
> have building architecture: so that the properties that we
> want our system
> to have remain in force throughout its implementation lifetime.
>
> <rant>
>
> The simple fact of the matter is that object-specific
> interfaces do not
> work across multiple organizational domains, no matter how
> many standards
> groups are convinced to standardize their cataloging and versioning.
> That is a lesson that should have been learned from all of
> the previous
> attempts to move DCOM and CORBA-like services onto the Internet.
> I think any such "improvements" should be required to
> demonstrate their
> effectiveness in practice, over a suitable length of time, before they
> can be considered as legitimate extensions to Web architecture.
>
> I think the Web works because it prevents object-specific
> attributes from
> defining the interface to the system.  Therefore, allowing
> such attributes
> to become part of the Web architecture, simply because a
> marketing campaign
> deems them to be so, is not only foolish but is contrary to the future
> well-being of the system we have worked so hard to create.
>
> Personally, I think it is completely outrageous when people
> claim that the
> Web architecture should be the one and only Internet application
> architecture.  I can understand the desire for URI to be
> universal, but not
> for the entire Web architecture. I like using fetchmail to
> grab my mail
> (how it does so is not very relevant because mail is a
> store-and-forward
> application architecture).  It doesn't make sense to limit the notion
> of Web architecture to URI just because it is the only universally
> applicable element.  URI is not sufficient to describe how
> the Web works.
> There are many systems outside of the Web that already use URI for
> identification, so identification alone does not define the Web.
>
> The fundamental notion that defines the Web is the
> interconnectedness of
> resources -- that everything which can be identified can also be
> ** indirectly ** described, manipulated, and related to other
> resources,
> and thereby can be traversed as an information space even when the
> resources themselves are not limited to documents.  This is possible
> because all interactions occur through a limited window of visibility.
> Whether an automobile viewed through the window represents a physical
> manifestation or a virtual simulation or a static image is completely
> irrelevant to the interface, even though it may be significant to the
> person using that interface [this is the place where RDF was supposed
> to be of benefit].  What prevents us from driving automobiles
> through a
> Web interface is the same thing that prevents us from doing so through
> object-specific interfaces: interaction latency and
> inadequate feedback.
> However, I can crash a car through a Web interface, and therefore the
> theory that a URI cannot identify a non-document resource is
> clearly false.
> There must be a hundred robots on the Web that prove it false.
>
> The distinction between what is part of the Web and what is not
> part of the Web is very easy to define: if at any time two components
> interact using a mechanism that cannot be understood without knowing
> the nature of the resource being accessed, then they are not
> using the Web
> architecture for their communication and are therefore (for
> the scope of
> that communication) outside of the Web.  If the interface is
> not uniform,
> all of the beneficial properties of the Web architecture that
> depend on
> uniformity are lost.
>
> [BTW, "component" is a term from software architecture -- a definition
> can be found in chapter 1 of my dissertation.]
>
> TELNET services are not part of the Web.  A "telnet" URL can be used
> within the Web to identify access to a TELNET service as a
> resource, but,
> once access to it is provided, the Web interface cannot participate
> in any further interaction.  It therefore makes sense that
> browsers direct
> such communication into a separate application, with its own
> communication
> architecture.  Likewise for mailto (which has absolutely
> nothing to do with
> access to mail messages *after* they have been posted).  In
> contrast, the
> old Gopher+ service was integrated into the Web architecture, with an
> acknowledged cost that the Web was unable to take advantage of some of
> the more advanced features of those services.  Again, the
> advantages of
> a uniform interface outweighed the loss of features.
>
> </rant>
>
> Cheers,
>
> Roy T. Fielding, Chairman, The Apache Software Foundation
>                  (fielding@apache.org)  <http://www.apache.org/>
>
>                  Chief Scientist, Day Software, Inc.
>                  2 Corporate Plaza, Suite 150
>                  Newport Beach, CA 92660-7929   fax:+1.949.644.5064
>                  (roy.fielding@day.com) <http://www.day.com/>
>
>

Received on Wednesday, 20 March 2002 01:14:29 UTC