Re: [rest-discuss] Newbie REST Question
- On Oct 1, 2009, at 4:19 AM, Nick Gall wrote:
> If (i) means "organizing its URI space in a stable manner", ie soWhy would navigating imply transient URIs?
> that bookmarking URIs works over long periods of time, then the
> practice of bookmarking is a violation of REST -- assuming that
> REST means minimizing dependency on stable URIs and instead
> navigating to potentially transient URIs via stable media types and
There are times when the best RESTful design will conflict
with UI guidelines (split-page processing) or browser limitations.
The goal here is not to run away screaming whenever something
doesn't match the ideal -- it is to recognize there is a
problem and find a way to compensate for it (e.g., by changing
the mode of interaction, using better clients, introducing
code to compress multiform steps into a single network
interaction, or just buying bigger machines).
Minimizing dependencies does not mean that one cannot
have a rich and well-defined URI space. Such dependencies
can be programmatically adjusted as whole trees of resources
just as easily as any single resource. However, that doesn't
mean that REST implies one particular design of URI space
is somehow "more RESTful" than some other design, which
was the original point being argued. Aside from the legacy
cache issues, any given organized structure is just as
good as any other organized structure, and both are better
than a disorganized structure. That's what we mean by
"it just doesn't matter to REST how you design your URIs."
IIRC, the complaint was about APIs that have a standard
URI structure. The problem with that is not the structure,
but rather the way that the structure is communicated to
clients (by antiquated agreement rather than by following
your nose). The follow-your-nose style has the built-in
capacity for indirection and redirection at the time
of the current interaction, whereas standard layouts
encourage the client to bake-in assumptions that will
That does not mean it isn't RESTful to have permanent URIs.
REST is still dependent on at least one starting URI, and
thus it is always going to be better for the URIs to be
permanent. It just isn't necessary to structure the
application around such permanence.
Bookmarks are resource identifiers from a prior interaction.
They are bread-crumbs. Sometimes they get eaten.
REST doesn't enter into the discussion until one of the
URIs is actively traversed and the application enters one of
its initial states. After that point the user agent is led
by the nose through the application. If the application is
designed correctly, then the only times that the user agent
will pause long enough to make a bookmark will be at one of
the application steady states, which should correspond to one
of the cool URIs. In other words, a RESTful architecture will
expose the cool URIs (and only the cool URIs) to the user.
REST cannot remove all the points of coupling. It can reduce
those points of coupling to the set of URIs that an organization
is willing to maintain over time for bookmarks (cool URIs).
How many of those you have is entirely up to the organization.
It is certainly possible for all of the URIs to be maintained.
- On Oct 2, 2009, at 10:39 PM, Nick Gall wrote:
> On Fri, Oct 2, 2009 at 3:38 PM, Subbu Allamaraju <subbu@...>Because, servers can still communicate all kinds of URIs to clients
>> On Oct 2, 2009, at 9:17 PM, Nick Gall wrote:
>>>> There are steady states and transient states. The
>>>> application should be designed such that clients/UAs don't need
>>>> to store
>>>> URIs for those transient state. Not every URI can be permanent.
>>>> Some URIs
>>>> may, by design, remain "uncool".
>>> So maybe we can use URI templates for the cool URIs (my photos, my
>>> blog posts, the books that Amazon offers, the songs that BBC radio
>>> plays) and HATEOAS (rel links in representations) for the uncool
>> I wouldn't draw a line like that, especially for the uncool ones.
> Why not?
using some hypertext means.
>> Looking at this thread so far, it seems to me that both TBL'sI don't disagree that it is not helpful, but such discussions can't be
>> position (that
>> every URI is permanent), and Roy's HATEOAS have been over-analyzed.
>> reality is a mix.
> Merely saying "its a mix" isn't helpful. Without some analysis and
> subsequent advice on issues such as...
done without some context.
>> Even the cool ones become uncool, and we can't continue to ignoreIt is not about the difficulty to keep URIs permanent/long-lived. Some
>> that and
>> preach coolness as a virtue.
> We can and should continue to preach coolness as a virtue, while
> acknowledging the reality of how difficult it is to be cool (as I
> think TimBL's design note does) and what to do when coolness fails.
URIs are by design ephemeral. Here is an example. A server may give a
client a link to make some updates. For security reasons, that link
may be valid for the next two minutes and gone afterwards. Here, the
sever did not fail to keep it cool. That link is not meant to be
permanent. That's all.