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

Re: [rest-discuss] Newbie REST Question

Expand Messages
  • Roy T. Fielding
    ... Why would navigating imply transient URIs? There are times when the best RESTful design will conflict with UI guidelines (split-page processing) or browser
    Message 1 of 67 , Oct 1, 2009
      On Oct 1, 2009, at 4:19 AM, Nick Gall wrote:
      > 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.

      Why would navigating imply transient URIs?

      There are times when the best RESTful design will conflict
      with UI guidelines (split-page processing) or browser limitations.
      The goal here is not to run away screaming whenever something
      doesn't match the ideal -- it is to recognize there is a
      problem and find a way to compensate for it (e.g., by changing
      the mode of interaction, using better clients, introducing
      code to compress multiform steps into a single network
      interaction, or just buying bigger machines).

      Minimizing dependencies does not mean that one cannot
      have a rich and well-defined URI space. Such dependencies
      can be programmatically adjusted as whole trees of resources
      just as easily as any single resource. However, that doesn't
      mean that REST implies one particular design of URI space
      is somehow "more RESTful" than some other design, which
      was the original point being argued. Aside from the legacy
      cache issues, any given organized structure is just as
      good as any other organized structure, and both are better
      than a disorganized structure. That's what we mean by
      "it just doesn't matter to REST how you design your URIs."

      IIRC, the complaint was about APIs that have a standard
      URI structure. The problem with that is not the structure,
      but rather the way that the structure is communicated to
      clients (by antiquated agreement rather than by following
      your nose). The follow-your-nose style has the built-in
      capacity for indirection and redirection at the time
      of the current interaction, whereas standard layouts
      encourage the client to bake-in assumptions that will
      inevitably break.

      That does not mean it isn't RESTful to have permanent URIs.
      REST is still dependent on at least one starting URI, and
      thus it is always going to be better for the URIs to be
      permanent. It just isn't necessary to structure the
      application around such permanence.

      Bookmarks are resource identifiers from a prior interaction.
      They are bread-crumbs. Sometimes they get eaten.

      REST doesn't enter into the discussion until one of the
      URIs is actively traversed and the application enters one of
      its initial states. After that point the user agent is led
      by the nose through the application. If the application is
      designed correctly, then the only times that the user agent
      will pause long enough to make a bookmark will be at one of
      the application steady states, which should correspond to one
      of the cool URIs. In other words, a RESTful architecture will
      expose the cool URIs (and only the cool URIs) to the user.

      REST cannot remove all the points of coupling. It can reduce
      those points of coupling to the set of URIs that an organization
      is willing to maintain over time for bookmarks (cool URIs).
      How many of those you have is entirely up to the organization.
      It is certainly possible for all of the URIs to be maintained.

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

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