Re: Bookmark 'stability'

On Sep 28, 2012 5:55 AM, "Mike Kelly" <mikekelly321 <[email protected]>
@ <[email protected]>gmail.com <[email protected]>> wrote:
>
> On Fri, Sep 28, 2012 at 9:46 AM, Ruben Verborgh <ruben.verborgh<[email protected]>
@ <[email protected]>ugent.be <[email protected]>> wrote:
> > Hi all,
> >
> >> "Cool URIs don't change" is not a RESTful principle.
> >
> > If there’s no stability, how can a REST system possibly work?
> > Okay, right, hypermedia… (assuming that at least the starting URI
remains stable)
> > but we can't expect clients to navigate to the desired resource every
time again, can we?
> >
>
> yes, why not?

Retracing the hypermedia trail to reset a busted bookmark when it becomes
is a Good Thing, but it is not always easy or even doable.

Some interactions which are simply repeatable. Ie, I go to bookstore api,
pick the most popular book today and bookmark it. The every day the app
checks and record its popularity so that I can see the trend over time. If
that bookmark stops working the app is pretty much screwed.

Retracing gets even harder if you have more than two components in the
distributed system. For example, say component A finds a resource and
passes its uri -- and by dong so effectively bookmarks the resource -- to
component B for future processing. If the uri stops working component B has
no way of acquiring the newer uri for the resource in question since only
component A knows what hypermedia trail should be followed.

In both of these hypothetical situations the entry point is the bookmarked
uri and there is no obvious way for the clients to automatically use any
other entry point. There many more situations like this once you get into
building real applications.

Peter
Barelyenough.org