- On Wed, Sep 30, 2009 at 5:40 PM, Jan Algermissen ... Either both are or neither are. If (i) means organizing its URI space in aMessage 1 of 67 , Oct 1, 2009View SourceOn Wed, Sep 30, 2009 at 5:40 PM, Jan Algermissen <algermissen1971@...> wrote:
> On Sep 30, 2009, at 11:11 PM, Bediako George wrote:Either both are or neither are.
> > I wonder if there is a subtle distinction between (i) the server
> > organizing its URI space in a predictable manner and (ii) the client
> > using that knowledge to construct/derive URIs to manipulate the
> > server? (i) does not seem to be in violation of REST, whereas (ii)
> > seems to be a violation of HATEOAS.
> (i) is a violation of REST if it is part of the contract between
> server and client.
> It's as easy as this: once the client makes use of the 'predictable
> way' of organisation the server cannot anymore change the way it
> organises the URI space. REST deliberately aims to avoid that.
If (i) means "organizing its URI space in a stable manner", ie so 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 HATEOAS.I raised this point back in February. Every time a client (whether a user client - aka browser - or not) bookmarks a link (aka stores it on the client side), it creates a dependency on the current URI space -- however it is organized. It doesn't matter if the URIs are opaque GUIDs or human-intuitive path-based. REST seems to suggest that creating (or encouraging) such dependencies is uncool.But Tim Berners-Lee et al seem to believe that being able to depend on stable URIs IS cool:
It is the the duty of a [URI space designer] to allocate URIs which you will be able to stand by in 2 years, in 20 years, in 200 years. This needs thought, and organization, and commitment.(TBL gives advice on how to achieve such URI stability.)If a cool (well-designed) URI space should be stable for 200 years, then it should be OK for clients to either bookmark them as received or to generate them from templates.So if REST discourages either URI bookmarking OR generating URIs from templates, then it is in tension with one of the fundamental principles of the Web: Cool URIs don't change. I think this is somewhat ironic.I'm not sure I agree with Roy that this tension is like sexual tension, but it IS an interesting comparison(!):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.-- Nick
- ... Because, servers can still communicate all kinds of URIs to clients using some hypertext means. ... I don t disagree that it is not helpful, but suchMessage 67 of 67 , Oct 3, 2009View SourceOn 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.