On Sep 27, 2008, at 2:18 PM, Nick Gall wrote:
> So does this mean, in a nutshell, that the architectural
> constraints that comprise the REST architectural style do NOT rule
> out centralized link servers?

Perhaps you should define what you mean by link servers. The term
has been variously used as a single source of unique token to location
mappings and/or active editing of content to replace relations.

REST constrains that there is a single system for identification of
resources and that said system identifies resources as a conceptual
mapping rather than a fixed content mapping. I am pretty sure one could
build a link server within that constraint, but I doubt that it would
be worth the investment.

> If so, I don't understand locutions such as "REST relies instead"
> and "REST designs around". REST is not an agent (a source of
> agency) with a will of its own. Only a (human) designer can "rely"
> or "design around". Correct?

REST is a set of design decisions made at many junctures along
the path of the Web. Most of them were not made by me in any sense
other than protecting those that worked and discarding those that did
not. So, aside from those parts of the architecture that I did design,
I prefer not to say that "I designed around ...". If you have a name
for the collective agent that reared its multitude of heads on the
www-talk mailing list and other private discussions surrounding the
core development teams from 92-95, then be my guest. We used to call
that collective the WWW Project, but it was really more of a loose
community of like-minded souls with stubborn opinions.

In any case, REST is an architectural style, which make REST an
agent of change when adherence to that style is self-imposed.
You will find the same grammatical usage in traditional architecture.

> For example, a designer attempting to rigorously follow REST's
> architectural constraints might nonetheless decide to build a
> scalable centralized link server. Such a designer would still
> deserve the appellation "RESTful designer" (ie one who faithfully
> follows the architectural constraints of REST). Correct?

Maybe (that's a rather small part of the overall architecture).
In any case, it is kind of pointless because the definition of
resource in REST is specifically designed to reduce the need for
link servers [which, traditionally, were intended to maintain
strict content relationships and not the abstract resource relations
that are found on the Web].

> Or the RESTful designer might try to build a decentralized link
> server in the style of DNS. Or finally, the RESTful designer may
> leave it up to each DNS-domain owner to maintain the integrity of
> links (the approach the thesis recommends).

DNS is not a link server. A link server manages both endpoints of a
link. A link server that only manages the end point of a link is just
a name resolution server, which is equivalent DNS and a subset of HTTP.

> All of these options are open to one faithfully following the
> architectural constraints of REST. A critic of one approach would
> have no right to say, "Your centralized link server approach is not
> RESTful." The worst one could say about such a design is, "Well,
> while you've faithfully followed the architectural constraints of
> REST, given the environmental constraints of the actual Web circa
> 2008, your approach turns out to be less scalable than the approach
> of leaving link forwarding up to the domain owners."
>
> Agreed?

I honestly don't give a rat's ass about architectural purity unless
it achieves a pure purpose. The purpose of REST is to explain why you
want to build it in a certain way given the Web's own context. If that
context doesn't exactly match a new application's context, then the
goal of
my dissertation is to teach people how to think about the problem in
terms
of trade-offs, not in terms of rigid repetition of what works for the
Web.

> Finally, given all this why NOT add a constraint to REST that rules
> out centralized link serving (and perhaps other centralized
> approaches)? Was the omission of such a constraint intentional?

It was intentional. More accurately, the specific change that I made to
the definition of resource (and in this case I really do mean "I") so
that
it emphasized a conceptual mapping instead of identifying the
representation
(the document returned at some past time) was specifically to obviate
the
need (or even desire) for hypertext link servers as described by the
prevailing hypertext research at the time. UCI was on the leading
edge of
hypertext research and I was well aware of those systems,
particularly when
they claimed they were better than the Web. The new definition also
matched
how people used URIs in practice, which is something I learned in my
early
research with MOMspider when I codified all of the ways that a link
could
"break" on the Web.

I think you will find that "A resource can map to the empty set, which
allows references to be made to a concept before any realization of that
concept exists" is rather difficult to provide with a link server unless
you also remove the integrity provisions (the entire point of having a
link server).

> It seems odd that an architectural style so associated with
> decentralization does not in fact explicitly constrain against
> centralized implementations. I for one was surprise to find that
> centralized approaches such as a centralized link server is NOT
> ruled out by REST.

It didn't have to. Seriously, it is hard enough defending the
constraints
that needed to exist. There is no reason to include additional stuff
like
"should not be used as a process control system inside a nuclear
reactor."

....Roy