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.


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.



Roy T. Fielding, Chairman, The Apache Software Foundation
                 (  <>

                 Chief Scientist, Day Software, Inc.
                 2 Corporate Plaza, Suite 150
                 Newport Beach, CA 92660-7929   fax:+1.949.644.5064
                 ( <>

Received on Tuesday, 19 March 2002 01:52:52 UTC