Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] Newbie REST Question

Expand Messages
  • Nick Gall
    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 a
    Message 1 of 67 , Oct 1, 2009
      On Wed, Sep 30, 2009 at 5:40 PM, Jan Algermissen <algermissen1971@...> wrote:
      > On Sep 30, 2009, at 11:11 PM, Bediako George wrote:
      > > 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.

      Either both are or neither are.

      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.

      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
    • Subbu Allamaraju
      ... 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 such
      Message 67 of 67 , Oct 3, 2009
        On Oct 2, 2009, at 10:39 PM, Nick Gall wrote:

        > On Fri, Oct 2, 2009 at 3:38 PM, Subbu Allamaraju <subbu@...>
        > wrote:
        >> 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
        >>> ones.
        >> I wouldn't draw a line like that, especially for the uncool ones.
        > Why not?

        Because, servers can still communicate all kinds of URIs to clients
        using some hypertext means.

        >> Looking at this thread so far, it seems to me that both TBL's
        >> position (that
        >> every URI is permanent), and Roy's HATEOAS have been over-analyzed.
        >> The
        >> reality is a mix.
        > Merely saying "its a mix" isn't helpful. Without some analysis and
        > subsequent advice on issues such as...

        I don't disagree that it is not helpful, but such discussions can't be
        done without some context.

        >> Even the cool ones become uncool, and we can't continue to ignore
        >> 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.

        It is not about the difficulty to keep URIs permanent/long-lived. Some
        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.

      Your message has been successfully submitted and would be delivered to recipients shortly.