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

Re: [rest-discuss] Re: RESTful URLs?

Expand Messages
  • Nick Gall
    ... Roy, thanks for responding. I completely agree that way REST dynamically provides the next relevant set of URIs via HATEOAS is highly dynamic, and dynamic
    Message 1 of 54 , Feb 6, 2009
    View Source
    • 0 Attachment
      On Fri, Feb 6, 2009 at 12:54 AM, Roy T. Fielding <fielding@...> wrote:
      >
      > On Feb 5, 2009, at 5:45 PM, Bill de hOra wrote:
      > > Assaf Arkin wrote:
      > >
      > >> On the other hand, in my experience it's easier to build code
      > >> around a
      > >> fixed URL structure, and if you only imagine having one (or few)
      > >> clients
      > >> to a single service, hypermedia might be an overkill.
      > >
      > > Also, hypertext for simple case tends to need two calls, one the
      > > bootstrap document to find the link, and two, to the actual link you
      > > care about. Whereas a fixed url scheme on the client means one call.
      >
      > Yes, a RESTful system is at least one level of indirection away
      > from a strongly coupled system. A fixed URL scheme is essentially
      > the same as baking the first representation into each client.
      >
      > Is that surprising?
      >
      > Likewise, a RESTful system is always going to be less efficient
      > than a system designed for a static set of clients accessing
      > a small set of services that never change.
      >
      > A lot of people think of systems as static things. Dead things.
      > REST is not going to appeal to those people. All of its constraints
      > are designed to keep systems living longer than we are willing
      > or able to anticipate.

      Roy, thanks for responding. I completely agree that way REST dynamically provides the next relevant set of URIs via HATEOAS is highly dynamic, and dynamic systems live longer than non-dynamic ones.

      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 space.

      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?

      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:

      1. "entry point" type URIs, which may be bookmarked indefinitely. These are Cool URIs.
      2. "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.
      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 URI should be a bookmarkable URI, ie that ALL URIs should strive to be Cool.

      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.

      Any light you can shed on this issue would be sincerely appreciated.

      -- Nick

    • mike amundsen
      One of this things I find I often confront is the dis-comfort folks experience when they identify the inefficiency of abstraction that is the result of the
      Message 54 of 54 , Feb 7, 2009
      View Source
      • 0 Attachment
        One of this things I find I often confront is the "dis-comfort" folks
        experience when they identify the "inefficiency of abstraction" that
        is the result of the loose coupling in the REST style.

        I usually address this comfort the same way I address the "premature
        optimization" issue.

        mca
        http://amundsen.com/blog/




        On Sat, Feb 7, 2009 at 07:54, Bill de hOra <bill@...> wrote:
        > Roy T. Fielding wrote:
        >>
        >>
        >> On Feb 5, 2009, at 5:45 PM, Bill de hOra wrote:
        >> > Also, hypertext for simple case tends to need two calls, one the
        >> > bootstrap document to find the link, and two, to the actual link you
        >> > care about. Whereas a fixed url scheme on the client means one call.
        >>
        >> Yes, a RESTful system is at least one level of indirection away
        >> from a strongly coupled system. A fixed URL scheme is essentially
        >> the same as baking the first representation into each client.
        >
        > Right. I think some people, when thinking about bootstrap problems
        > (which is what we're talking about here), end up in logical knots and
        > fallacies, or worse, invent pointless discovery technologies to solve a
        > non-problem. The first link is always out of band, get over it.
        >
        >> Is that surprising?
        >
        > Obviously not, but it seemed fair to point it out.
        >
        > Bill
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.