On Thursday, October 2, 2003, at 07:15 AM, Walden Mathews wrote:

> I don't think it would ever be correct to say that "REST [or
> any architectural style, for that matter] is only about the technical
> aspects...". The purpose of studying architectural styles is so
> that we can reason about the properties of the system.
>
> In this case, there are two properties driving the definition of
> "resource" within the REST style:
>
> (1) consistency of reference. When you say "GET the algorithm
> for computing the area of a circle" or "GET the current weather
> in Norwalk", you want those requests to have consistent semantics
> over time. Even if the particular answers vary.
>
> (2) scaleability. One way to achieve that consistency is to let
> identifiers identify representations, and rely on centralized link
> services to
> track state changes. Every time the current weather in Norwalk
> changed, a new document and a new identifier would have to be
> minted, and all existing documents with a reference to Norwalk
> weather would need their links updated, the overall cost of the
> operation
> being commensurate with the total number of such links. The other,
> more scaleable, way to achieve that is to do what REST does:
>
> """
> Traditional hypertext systems [61], which typically operate in a
> closed or
> local environment, use unique node or document identifiers that change
> every
> time the information changes, relying on link servers to maintain
> references
> separately from the content [135]. Since centralized link servers are
> an
> anathema to the immense scale and multi-organizational domain
> requirements
> of the Web, REST relies instead on the author choosing a resource
> identifier
> that best fits the nature of the concept being identified. Naturally,
> the
> quality of an identifier is often proportional to the amount of money
> spent
> to retain its validity, which leads to broken links as ephemeral (or
> poorly
> supported) information moves or disappears over time.
> """
>
> I don't think REST seeks to be a framework for knowledge
> representation or semantics. I think the requirements above led
> to its definition being inevitably "conceptual".

That's an excellent summary, Walden. REST does not seek to be a
framework for KR, but it is a framework for communication. The KR
systems that I am familiar with are primarily based on models of
facts/claims/reality instead of perceptions, since building a
reasoning system with multiple perspectives is a bit like
working with a schizophrenic. However, since communication is
at the heart of learning, they end up with similar challenges.
and similar terminology.

> REST "resource" is unlike any other architectural component
> I am aware of in this sense. A "filter" component in a pipe &
> filter style makes promises about the consistency and relative
> statelessness of the transform, but not any semantic consistency
> of the output.

Yep, I struggled with that in writing the dissertation -- is
each resource a datum, a connector, a component, or something
else that just hasn't been talked about in the literature?
I think of it as an abstract goal, more than anything else,
but classified it as data because it didn't fit elsewhere.
It is, essentially, data that is only used by reference.

> In modeling REST formally, you can remove "resource" from
> the picture without harming the purely technical aspects of the
> system. What you then end up with is a many-to-many relation
> from URI to representations. Perhaps that's all the Web *really*
> is, but it's hard to find any guidance in the building of useful
> systems in that. Put another way, it's hard to decide what value
> such a system might be providing.

And that is the key, really, since the main reason we know that a
conceptual resource must exist is because of the number of ways
that a link can fail. It is only when people complain bitterly
about the lack of an expected sameness that you realize the goal
of the link has nothing to do with the listener at the end of
the HTTP address, but rather the expectation that it identifies
(indirectly, as there is no such thing as direct HTTP
identification) something other than the address.

People don't create links to server software; they create links to
information. If the system pretends that the target of a link is
nothing more than a communication point, then the system cannot
anticipate and correct for the kinds of information failures that
people actually care about. Or, more to the point, people won't
design the system (which doesn't care either way) such that it
detects such failures when possible and includes the features
necessary for indirection, redirection, etc.

BTW, the definition of resource in REST applies only to information
systems. The one that applies to all uses of URI is in the
rfc2396bis draft, which has larger scope but ends up being less
useful as a result. There are no other generally agreed upon
definitions of resource for the Web technologies, though many people
still think of it as a "document" and simply change the definition
of document to have the same properties as a resource.

....Roy