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

Re: [rest-discuss] Which URIs are bookmarkable?

Expand Messages
  • Mike Kelly
    On Tue, Oct 11, 2011 at 11:18 AM, Jan Algermissen ... Right, this is actually one of my issues with Atom because, in my opinion, there should be complete
    Message 1 of 9 , Oct 11, 2011
    • 0 Attachment
      On Tue, Oct 11, 2011 at 11:18 AM, Jan Algermissen
      <jan.algermissen@...> wrote:
      >
      > On Oct 11, 2011, at 12:07 PM, Mike Kelly wrote:
      >
      >> On Tue, Oct 11, 2011 at 10:42 AM, Jan Algermissen
      >> <jan.algermissen@...> wrote:
      >>>
      >>> On Oct 11, 2011, at 11:23 AM, Mike Kelly wrote:
      >>>
      >>>> A given application should specify its entry points explicitly
      >>>
      >>> This cannot work because the application only comes into existence based on the choices the client makes.
      >>
      >> Do you mean application state?
      >>
      >> Either way, not sure I understand your point; AtomPub is an
      >> application, and it exists.
      >
      > No, AtomPub is a media type that enables a certain set of applications.
      >

      Right, this is actually one of my issues with Atom because, in my
      opinion, there should be complete separation between the media type
      and the 'application' i.e. hal (media type) and a set of link
      relations (the application).

      >
      >The AtomPub spec suggests a set of canonical[1] applications. But there are certainly many, many others. For example, crawling a dozen of feeds and building an index of posts is one that is not in the AtomPub spec.
      >

      That's just a client performing multiple "applications" (I believe the
      Jian™ terminology for this is Domain Application Protocol™) in a
      particular sequence. Yes, there's some unique application state stuff
      involved on the client side but that's not related to the AtomPub
      application/DAP I was referring to originally and, more to the point,
      isn't actually visible to the network. If you create a user agent that
      generates and manages some application state of its own that's great
      but I don't see what that has to do with bookmark-ability of the
      resources or the Domain Application Protocols™ it's engaging in. The
      DAPs are what is informing your user-agent of the significance of
      given resources, and that is where (if at all) any potential entry
      points should be specified.

      Cheers,
      Mike
    • Erik Mogensen
      On Tue, Oct 11, 2011 at 9:40 AM, Jan Algermissen
      Message 2 of 9 , Oct 11, 2011
      • 0 Attachment
        On Tue, Oct 11, 2011 at 9:40 AM, Jan Algermissen <jan.algermissen@...> wrote:

        [...] In general, I am trying to answer the question:

        What are the indicators in media type (and link relation) specifications that tell
        the user agent implementor what URIs in responses of the media type in question
        can be considered bookmarkable?


        Isn't it the prose in the media type specification itself?  A media type indicates that activating a particular hypermedia control advances the user agent to a new application state.  If that ends up in a "safe" state (i.e. it ends up with a GET'able resource) then that means that it's a "bookmarkable state" and one that's worthy of a future entry point.

        Example: if a form directs you to POST something to a URI and it responds with a redirect to another resource, and the agent automatically follows that cue, then that new resource would IMHO be a bookmarkable state.

        HTML states this clearly for <A>: "By activating these links [...], users may visit these resources." [1].  For  <IMG> images are to be "embedded [...] in the current document" [2].

        --
        -mogsie-
      • Jan Algermissen
        ... HA! It has been in the archives all along (thanks, Roy :-) If the application is designed correctly, then the only times that the user agent will pause
        Message 3 of 9 , Oct 30, 2011
        • 0 Attachment
          On Oct 11, 2011, at 9:40 AM, Jan Algermissen wrote:

          > Hi,
          >
          > how do I decide whether a URI is bookmarkable or not?

          HA! It has been in the archives all along (thanks, Roy :-)

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

          http://tech.groups.yahoo.com/group/rest-discuss/message/13606

          Jan


          >
          > ('Bookmarkable' meaning: 'Being an entry point into an application that is worth remembering')
          >
          > Some things to consider:
          >
          > There is a difference between the stability of a URI (whether a client can asssume a URI will
          > be dereferencable in the future) and the suitability of a URI to act as an application entry point.
          > For example, I'd assume HTML style sheet URIs to be pretty stable but they are not useful
          > application entry points.
          >
          > Should a user agent remember as many URIs as possible, thereby increasing the amount of
          > known application entry points and possibly avoiding re-doing certai steps through the
          > application in the future (sth we do all the time when bookmarking e.g. page 4 of
          > a search result).
          >
          > o All URIs I find in responses from a server in a link context are bookmarkable
          > ('Link context' meaning Atom <link> elemnts, HTML <a> elements, Link headers,
          > HTML GET-forms, etc.)
          >
          > o Not all URIs I find in responses from a server are bookmarkable. For example,
          >
          > - a URI I find in an HTML <form> element with action 'POST' is not
          > - a URI I find in an Opensearch <Url> element is not
          > - a URI I find in an HTML <style> element is not
          >
          > o What about
          >
          > - a URI I find in an HTML <img> element
          > - a URI I find in an AtomPub <collection> element
          > - a URI I find in HTTP headers such as Location, Content-Location, Alternates
          > - AtomPub's edit-media links?
          > - Atom <content src=""> references
          >
          > Does the cachability of a response affect these issues?
          >
          > In general, I am trying to answer the question:
          >
          > What are the indicators in media type (and link relation) specifications that tell
          > the user agent implementor what URIs in responses of the media type in question
          > can be considered bookmarkable?
          >
          > JAn
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.