On Feb 6, 2009, at 4:03 AM, Nick Gall wrote:
> But you didn't address the (apparent) tension between bookmarking/
> deep-linking and REST, which was my original question. Bookmarking
> takes a dynamically generated bookmark and effectively makes it
> static -- at least it's static (persisted) on the client side. As
> more and more clients bookmark more and more of the URIs they
> receive, the more they are incrementally "fixing" the original URI
> Hence my point: encouraging promiscuous bookmarking of (deep) links
> seems to be at odds with REST's desire to minimize "entry point"
> URIs. Do you see the tension as well, or am I missing something
> that resolves the tension?
Why do you think that there is a desire in REST to minimize the
number of entry points?
> Devdatta makes the excellent point earlier in the thread about "how
> blogs require you to permalink instead of the page you are
> viewing." It seems that perhaps there is an implicit REST
> constraint that is beginning to become more explicit. Roughly, REST
> distinguishes two types of URIs:
> "entry point" type URIs, which may be bookmarked indefinitely.
> These are Cool URIs.
> "transitional" type URIs, which may not be bookmarked indefinitely.
> These are unCool URIs. I call then "transitional" given that their
> role is typically to enable transition to the next state.
No. There are some crappy web applications that expose what you would
call a transitional (partial web state) URI to the client because
they are badly written to expose an old terminal screen interface
as intermediate HTML forms, but I would not call such a system RESTful.
Those URIs are not identifying resources.
Permalinks provide a URI to the article resource that is independent
of its current representation (usually, the representation of some feed,
which is not the same resource and hence requires the provision of a
permalink URI for people to bookmark). It is just hypertext and has
the same role in REST as the list of summaries that Google returns
in response to a search.
> I'm not wedded to the names (you could call them internal/
> external), but I do think this distinction between types of URIs is
> an important aspect of REST that, so far, has not been clearly
> outlined. It certainly seems to be in play in the permathread
> debates regarding whether "URIs should be RESTful or not" (and
> whether that designation is even a meaningful one). I also think
> the distinction is a bit at odds with the common understanding of
> URIs on the Web that ANY URIshould be a bookmarkable URI, ie that
> ALL URIs should strive to be Cool.
I won't repeat my opinion about opaque URIs. If there is a
tension between the desire to bookmark and the fact that REST
encourages folks to break up an application into a state
machine of reusable resource states, then I would consider it to be
more like sexual tension. Just because you have it doesn't mean
it is bad, and one way to improve things is to make the more
important resource links look sexier than the less important ones.
> I think it's a pretty major change in Web architectural thinking
> (or at least emphasis) to now say (effectively) that a significant
> class of URIs should NOT be cool, ie one should NOT expect them to
> be useable indefinitely. In a way, this harks all the way back to
> Parnas's admonition that we hide information that is likely to
> change. Using modern web-speak, REST seems to admonish us to "hide"
> the URIs that are likely to change (unCool URIs) and "expose" only
> those URIs that are likely to stay the same (Cool URIs). But
> nothing I've seen in the desciptions of Web Architecture (eg
> AWWWv1) remotely suggests that some URIs should effectively be
> hidden, or per my previous point, not bookmarked. If anything, Web
> Architecture descriptions at least imply that all URIs SHOULD be
> "exposed" and bookmarkable.
"All important resources should be identifiable by URI."
I think you should look at each of those words in turn and
consider why they were chosen. That particular quote is from
but it was also in the first drafts of the TAG's webarch. That
principle was not new -- I remember TimBL mentioning it during his
keynote in Geneva, May 1994, and it dates from Engelbart's work:
which in turn influenced my design when HTTP/1.0 needed finishing.
By definition, working on improving the Web Project meant increasing
the number of Web-accessible resources.
Here is a more recent variation on the same theme that I just ran
across while doing a search:
Other things that might be worth keeping in mind is that REST is
designed for reuse, not just use. The notion that anyone has control
over a successful application's reuse is pure fantasy, as described in