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

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

Expand Messages
  • Roy T. Fielding
    ... Why do you think that there is a desire in REST to minimize the number of entry points? ... No. There are some crappy web applications that expose what
    Message 1 of 54 , Feb 6, 2009
    View Source
    • 0 Attachment
      On Feb 6, 2009, at 4:03 AM, Nick Gall wrote:
      > 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?

      Why do you think that there is a desire in REST to minimize the
      number of entry points?

      > 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:
      >
      > "entry point" type URIs, which may be bookmarked indefinitely.
      > These are Cool URIs.
      > "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.

      No. There are some crappy web applications that expose what you would
      call a transitional (partial web state) URI to the client because
      they are badly written to expose an old terminal screen interface
      as intermediate HTML forms, but I would not call such a system RESTful.
      Those URIs are not identifying resources.

      Permalinks provide a URI to the article resource that is independent
      of its current representation (usually, the representation of some feed,
      which is not the same resource and hence requires the provision of a
      permalink URI for people to bookmark). It is just hypertext and has
      the same role in REST as the list of summaries that Google returns
      in response to a search.

      > 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 URIshould be a bookmarkable URI, ie that
      > ALL URIs should strive to be Cool.

      I won't repeat my opinion about opaque URIs. 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.

      http://www.bootstrap.org/augdocs/augment-132082.htm#11J

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

      "All important resources should be identifiable by URI."

      I think you should look at each of those words in turn and
      consider why they were chosen. That particular quote is from

      http://www.w3.org/2001/tag/2002/01-uriMediaType-9
      and
      http://www.w3.org/2002/04/22-tag-summary

      but it was also in the first drafts of the TAG's webarch. That
      principle was not new -- I remember TimBL mentioning it during his
      keynote in Geneva, May 1994, and it dates from Engelbart's work:

      http://www.bootstrap.org/augdocs/augment-132082.htm#11K

      which in turn influenced my design when HTTP/1.0 needed finishing.
      By definition, working on improving the Web Project meant increasing
      the number of Web-accessible resources.

      Here is a more recent variation on the same theme that I just ran
      across while doing a search:

      http://derivadow.com/2007/12/28/web-design-20-its-all-about-the-
      resource-and-its-url/

      Other things that might be worth keeping in mind is that REST is
      designed for reuse, not just use. The notion that anyone has control
      over a successful application's reuse is pure fantasy, as described in

      <http://www.w3.org/mid/E6416F61-E40C-4DE6-8B7A-D8A94EE8537B@...>

      ....Roy
    • 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.