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

Re: Rel attributes?

Expand Messages
  • paul_k_moore
    William This is very useful - thank you. Just to confirm my (refined) understanding here, I consider the meaning of rel to be an orthogonal concern to the
    Message 1 of 23 , May 3, 2012
    • 0 Attachment
      William

      This is very useful - thank you.

      Just to confirm my (refined) understanding here, I consider the meaning of 'rel' to be an orthogonal concern to the HTTP methods.

      To expound slightly, I had erroneously conflated the HTTP methods (avaialble at the target URI) into the meaning of 'rel'. If we consider the following two examples:

      Example 1: Use of a 'rel' such as 'http://relations.example.com/order' reasonably conveys to the user-agent that there is something 'order'-like at the target URI. It is then up to the client (the client intent) to follow this rel (using an implicit GET request) to retrieve the representation of the 'order'-like thing (as rendered in a specific media-type).

      Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to (unreasonably) convey that the user agent can POST an item of the type communicated by it's current context. This is the problem, I don't need to 'say' to the user-agent that it can POST at a specific URI, because the available HTTP methods tell me what I can do with the resource. What I need to do is examine the permitted methods (either by inspection of the 'Allow' header, or an OPTIONS request) AND not try to convey the permutations of method in the 'rel'.

      Does that make sense?

      Thanks in advance

      Paul

      --- In rest-discuss@yahoogroups.com, "William Martinez Pomares" <wmartinez@...> wrote:
      >
      > Hi nikonguy74!
      > Just to complement what Jan is saying:
      > 1. Links represent resources you can work with. The idea of links is that you can usually follow them (issuing a GET operation), but then there are lots of questions you may have about them: what do I do with the actual resource (say, web page) I'm in? What is this link referring to? What other operations apart from GET can I execute with it? Can I add query parameters to it? What media type will it return? What media type may it expect if I can issue a POST?, etc...
      >
      > 2. rel is an attribute to add more information about a link. I denotes a value, keyword, hint of what relation the link has with the current resource/IRI. Say you are in a book page, that is your current resources and it has a URI. A link with rel="next" will hint that following that link will get you to the next page of the book.
      >
      > 3. It is important to understand that the rel is the relation the resource identified by the link's URI, has with the actual resource/uri/document. It is not good if you use rel to denote other information, like saying rel="CreateWithPost" to hint the agent to use the link's URI with a POST to create something. That is not the intended use and it is a bad practice.
      >
      > 4. You may need actual business intelligence in your client. If you are looking at a blog comment, a rel="parent" will tell you the links points to the actual blog post. Having that information, you can start asking that parent for information, or even send a comment to it using POST operation. That is natural simply because much of this interaction is already designed in the specs, and the agent may not need to be statically programmed, but it will need intelligence.
      >
      > 5. So, you have there standard metainformation (like how to handle media types, the semantics of POST and PUT, the semantics or link and rel), etc. Plus, you have business specific semantics (the actual value of the rel may mean something applicable only to, say, banking applications). With that info you can program intelligent clients.
      >
      > 6. Finally, some other "link" tags like anchor and image are special links that have a standard meaning and established processing. If you found an <img> tag you automatically know that link is referring to an image, and if you are in HTML page in a browser, the supposed processing it to fetch that image with a GET and display it based on context and additional attributes. All that is told by the tag name, and everybody in the world knows it. So, links are difficult to understand at first but once you have it clear they are simple to use. Only don't expect the link rel attribute will tell you everything.
      >
      > Cheers
      >
      > William Martinez.
      > --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@> wrote:
      > >
      > >
      > > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
      > > >
      > > > I know one of the first questions i had was on rel link. I understand the basic premise behind rel attributes(to provide a general documentation for how to interact with the link provider).
      > >
      > > The premise of the rel attribute on links is (in the case of the HTML or Atom media types) to provide information about the meaning of the link beyond 'this is a link'. If you register your rel name in the IANA registry, you can use the short name you registered, e.g. 'next' or 'up'. If you did not register your rel, you need to provide a URI. Simply for the matter of making your rel unambiguous.
      > >
      > > If that URI points to a human readable page explaining the relation, then that is even better.
      > >
      > > There is no magic (not even in REST :-) that removes the need to implement in code (or configure) what the user agent should do when it sees your link rel value.
      > >
      > > <link rel="http://foo/customerDetails" ... /> is conceptually the same as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or AtomPub's <collection href="..."/>. It is just hypermedia ... that a user agent needs to be programmed to do something with ... in order to have it do something with it.
      > >
      > > IOW, your browser downloads that image because it is programmed to do so. This same concept also applies to other hypermedia - your user agent component will act on the hypermedia it comes across in the way it is programmed (or configured) to do.
      > >
      > > No magic.
      > >
      > > The effect of the hypermedia constraint is actually more felt in the obligations you have as a client side programmer (to react to the hypermedia you actually come across instead of the one you presume to come across) than it is felt in the aspect of loose coupling.
      > >
      > > REST mostly makes explicit that there isn't any control over the server side in networked systems. REST encourages you to deal with that rather than magically solves a problem that cannot be solved. And on top of that, REST provides a number of mechanism that optimize for *dealing with* the problem (e.g. content negotiation).
      > >
      > > HTH,
      > >
      > > Jan
      > >
      > > > The question is what would you see if you go to the rel link? Is it something a person is suppose to interact with (say to get documentation for new links added to a specific response) or something code can interact with to determine what it needs to do? Unfortunately in the book they don't give an example of what a "rel" page would look like. For example the link:
      > > > <link rel="http://relations.restbucks.com/payment"
      > > > href:="http://restbucks.com/payment/1234" />
      > > >
      > > > If you typed in "http://relations.restbucks.com/payment" into your web browser what would you see?
      > > >
      > > > thanks...
      > > >
      > > >
      > >
      >
    • Rushforth, Peter
      Hi Paul, In atompub, the rel= edit link relation means you can PUT or DELETE to the href. Also in atompub, app:collection/accept/text() tells you you can POST
      Message 2 of 23 , May 4, 2012
      • 0 Attachment
        Hi Paul,
         
        In atompub, the rel="edit" link relation means you can PUT or DELETE to the href.
         
        Also in atompub, app:collection/accept/text() tells you you can POST the app:collection/@href whatever MIME types are 
        listed in the app:accept text().
         
        Going by that as an exemplar, it seems to me that it is the hypermedia format which is defining what can and can't be
        done against the URL.  Maybe that is out of band knowledge, but then again, knowing what @method="POST" means
        could be considered out of band too.   It has to be written down somewhere and agreed to.  So the sharing of the semantics
        widely is key to interoperability.  Hence a public link relations registry.   It is the shared semantics that allows us to
        program user agents to do predictable things when they come across a particular hypermedia construct.
         
        Maybe it is important that when a GET is done on a resource, that the response metadata also declare the available methods.
        Message metadata is authoritative.
         
        But you should not have to do that GET, because it is a waste of bandwidth, and the representation format has already
        defined (in the registry) and declared (in the instance in which you find the href) the (possibly implicit) method availabilities.
         
        > 3. It is important to understand that the rel is the relation the resource identified by the link's URI, has with the actual resource/uri/document. It is not good if you use rel to denote other
        information, like saying rel="CreateWithPost" to hint the agent to use the link's URI with a POST to create something. That is not the intended use and it is a bad practice.
        It seems reasonable to me, I don't see why it is a bad practice.  It looks a lot like the atom:link@rel="edit", or html's @method="POST". 
         
        Cheers,
        Peter
         


        From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of paul_k_moore
        Sent: May 3, 2012 11:00
        To: rest-discuss@yahoogroups.com
        Subject: [rest-discuss] Re: Rel attributes?

         



        William

        This is very useful - thank you.

        Just to confirm my (refined) understanding here, I consider the meaning of 'rel' to be an orthogonal concern to the HTTP methods.

        To expound slightly, I had erroneously conflated the HTTP methods (avaialble at the target URI) into the meaning of 'rel'. If we consider the following two examples:

        Example 1: Use of a 'rel' such as 'http://relations.example.com/order' reasonably conveys to the user-agent that there is something 'order'-like at the target URI. It is then up to the client (the client intent) to follow this rel (using an implicit GET request) to retrieve the representation of the 'order'-like thing (as rendered in a specific media-type).

        Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to (unreasonably) convey that the user agent can POST an item of the type communicated by it's current context. This is the problem, I don't need to 'say' to the user-agent that it can POST at a specific URI, because the available HTTP methods tell me what I can do with the resource. What I need to do is examine the permitted methods (either by inspection of the 'Allow' header, or an OPTIONS request) AND not try to convey the permutations of method in the 'rel'.

        Does that make sense?

        Thanks in advance

        Paul

        --- In rest-discuss@yahoogroups.com, "William Martinez Pomares" <wmartinez@...> wrote:
        >
        > Hi nikonguy74!
        > Just to complement what Jan is saying:
        > 1. Links represent resources you can work with. The idea of links is that you can usually follow them (issuing a GET operation), but then there are lots of questions you may have about them: what do I do with the actual resource (say, web page) I'm in? What is this link referring to? What other operations apart from GET can I execute with it? Can I add query parameters to it? What media type will it return? What media type may it expect if I can issue a POST?, etc...
        >
        > 2. rel is an attribute to add more information about a link. I denotes a value, keyword, hint of what relation the link has with the current resource/IRI. Say you are in a book page, that is your current resources and it has a URI. A link with rel="next" will hint that following that link will get you to the next page of the book.
        >
        > 3. It is important to understand that the rel is the relation the resource identified by the link's URI, has with the actual resource/uri/document. It is not good if you use rel to denote other information, like saying rel="CreateWithPost" to hint the agent to use the link's URI with a POST to create something. That is not the intended use and it is a bad practice.
        >
        > 4. You may need actual business intelligence in your client. If you are looking at a blog comment, a rel="parent" will tell you the links points to the actual blog post. Having that information, you can start asking that parent for information, or even send a comment to it using POST operation. That is natural simply because much of this interaction is already designed in the specs, and the agent may not need to be statically programmed, but it will need intelligence.
        >
        > 5. So, you have there standard metainformation (like how to handle media types, the semantics of POST and PUT, the semantics or link and rel), etc. Plus, you have business specific semantics (the actual value of the rel may mean something applicable only to, say, banking applications). With that info you can program intelligent clients.
        >
        > 6. Finally, some other "link" tags like anchor and image are special links that have a standard meaning and established processing. If you found an <img> tag you automatically know that link is referring to an image, and if you are in HTML page in a browser, the supposed processing it to fetch that image with a GET and display it based on context and additional attributes. All that is told by the tag name, and everybody in the world knows it. So, links are difficult to understand at first but once you have it clear they are simple to use. Only don't expect the link rel attribute will tell you everything.
        >
        > Cheers
        >
        > William Martinez.
        > --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@> wrote:
        > >
        > >
        > > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
        > > >
        > > > I know one of the first questions i had was on rel link. I understand the basic premise behind rel attributes(to provide a general documentation for how to interact with the link provider).
        > >
        > > The premise of the rel attribute on links is (in the case of the HTML or Atom media types) to provide information about the meaning of the link beyond 'this is a link'. If you register your rel name in the IANA registry, you can use the short name you registered, e.g. 'next' or 'up'. If you did not register your rel, you need to provide a URI. Simply for the matter of making your rel unambiguous.
        > >
        > > If that URI points to a human readable page explaining the relation, then that is even better.
        > >
        > > There is no magic (not even in REST :-) that removes the need to implement in code (or configure) what the user agent should do when it sees your link rel value.
        > >
        > > <link rel="http://foo/customerDetails" ... /> is conceptually the same as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or AtomPub's <collection href="..."/>. It is just hypermedia ... that a user agent needs to be programmed to do something with ... in order to have it do something with it.
        > >
        > > IOW, your browser downloads that image because it is programmed to do so. This same concept also applies to other hypermedia - your user agent component will act on the hypermedia it comes across in the way it is programmed (or configured) to do.
        > >
        > > No magic.
        > >
        > > The effect of the hypermedia constraint is actually more felt in the obligations you have as a client side programmer (to react to the hypermedia you actually come across instead of the one you presume to come across) than it is felt in the aspect of loose coupling.
        > >
        > > REST mostly makes explicit that there isn't any control over the server side in networked systems. REST encourages you to deal with that rather than magically solves a problem that cannot be solved. And on top of that, REST provides a number of mechanism that optimize for *dealing with* the problem (e.g. content negotiation).
        > >
        > > HTH,
        > >
        > > Jan
        > >
        > > > The question is what would you see if you go to the rel link? Is it something a person is suppose to interact with (say to get documentation for new links added to a specific response) or something code can interact with to determine what it needs to do? Unfortunately in the book they don't give an example of what a "rel" page would look like. For example the link:
        > > > <link rel="http://relations.restbucks.com/payment"
        > > > href:="http://restbucks.com/payment/1234" />
        > > >
        > > > If you typed in "http://relations.restbucks.com/payment" into your web browser what would you see?
        > > >
        > > > thanks...
        > > >
        > > >
        > >
        >

      • Paul Moore
        Peter, Caveat: I am not an ATOM expert, happy to be corrected. I have investigated the edit link relation previously and concluded that the semantics are
        Message 3 of 23 , May 4, 2012
        • 0 Attachment
          Peter,

          Caveat: I am not an ATOM expert, happy to be corrected.

          I have investigated the 'edit' link relation previously and concluded that the semantics are confused.

          The definition from ATOMPUB is:

          "The value of "edit" specifies that the value of the href attribute is the IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Resource represented by that Entry..."

          So, actually 'edit' means GET, PUT, DELETE (in at least one context :-).  We could have a conversation about what 'self' means (a restatement of GET?), but let's park that for a moment.

          Then latterly in the Spec there's this, which informs us that the member entry in a feed may not be complete. 

          "Clients MUST NOT assume that an Atom Entry returned in the Feed is a full representation of an Entry Resource and SHOULD perform a GET on the URI of the Member Entry before editing it."

          This is (at best) annoying for a user-agent which has to either (i) understand the completeness of the member entry in the feed - for which I see no mechanism to determine, or (ii) must always execute a GET, PUT cycle to make a change.  If a GET is required anyway, there are other standard mechanisms to inform the user-agent of the permitted methods (e.g. 'Allow' header).  I consider this part of the spec to somewhat of an over-constraint, and would rather 'edit' was defined as "an intent to do some editing".

          Additionally, the conflation of method with rel here gives rise to a considerable number of missing permutations of resource state transition i.e. what about resources I can GET & DELETE but not PUT (does 'edit' still apply?); GET & POST (nothing defined).  Anyway, you get my point I'm sure.

          </rant>

          I haven't investigated the app:collection/@href semantics - I'll take a look :-)

          I agree the semantics of 'rel' need to be documented in the media type - this is one of the reasons I think we need specific media types for (new) domain problems.  Today's 'special' link relations are the standards of tomorrow - after agreement.

          Additionally, the semantics of the link relation can (and do) change with the (current) context of the application, so these context based refinements of rel semantics also need to go in the media type.

          So, I'm still on the side that the method and rel should be orthogonal concerns, and that atompub's 'edit' does not help here.

          Best regards

          Paul

          On 4 May 2012, at 13:28, Rushforth, Peter wrote:

          Hi Paul,
           
          In atompub, the rel="edit" link relation means you can PUT or DELETE to the href.
           
          Also in atompub, app:collection/accept/text() tells you you can POST the app:collection/@href whatever MIME types are 
          listed in the app:accept text().
           
          Going by that as an exemplar, it seems to me that it is the hypermedia format which is defining what can and can't be
          done against the URL.  Maybe that is out of band knowledge, but then again, knowing what @method="POST" means
          could be considered out of band too.   It has to be written down somewhere and agreed to.  So the sharing of the semantics
          widely is key to interoperability.  Hence a public link relations registry.   It is the shared semantics that allows us to
          program user agents to do predictable things when they come across a particular hypermedia construct.
           
          Maybe it is important that when a GET is done on a resource, that the response metadata also declare the available methods.
          Message metadata is authoritative.
           
          But you should not have to do that GET, because it is a waste of bandwidth, and the representation format has already
          defined (in the registry) and declared (in the instance in which you find the href) the (possibly implicit) method availabilities.
           
          > 3. It is important to understand that the rel is the relation the resource identified by the link's URI, has with the actual resource/uri/document. It is not good if you use rel to denote other information, like saying rel="CreateWithPost" to hint the agent to use the link's URI with a POST to create something. That is not the intended use and it is a bad practice.
          It seems reasonable to me, I don't see why it is a bad practice.  It looks a lot like the atom:link@rel="edit", or html's @method="POST". 
           
          Cheers,
          Peter
           


          From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On Behalf Of paul_k_moore
          Sent: May 3, 2012 11:00
          To: rest-discuss@yahoogroups.com
          Subject: [rest-discuss] Re: Rel attributes?

           



          William

          This is very useful - thank you.

          Just to confirm my (refined) understanding here, I consider the meaning of 'rel' to be an orthogonal concern to the HTTP methods.

          To expound slightly, I had erroneously conflated the HTTP methods (avaialble at the target URI) into the meaning of 'rel'. If we consider the following two examples:

          Example 1: Use of a 'rel' such as 'http://relations.example.com/order' reasonably conveys to the user-agent that there is something 'order'-like at the target URI. It is then up to the client (the client intent) to follow this rel (using an implicit GET request) to retrieve the representation of the 'order'-like thing (as rendered in a specific media-type).

          Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to (unreasonably) convey that the user agent can POST an item of the type communicated by it's current context. This is the problem, I don't need to 'say' to the user-agent that it can POST at a specific URI, because the available HTTP methods tell me what I can do with the resource. What I need to do is examine the permitted methods (either by inspection of the 'Allow' header, or an OPTIONS request) AND not try to convey the permutations of method in the 'rel'.

          Does that make sense?

          Thanks in advance

          Paul

          --- In rest-discuss@yahoogroups.com, "William Martinez Pomares" <wmartinez@...> wrote:
          >
          > Hi nikonguy74!
          > Just to complement what Jan is saying:
          > 1. Links represent resources you can work with. The idea of links is that you can usually follow them (issuing a GET operation), but then there are lots of questions you may have about them: what do I do with the actual resource (say, web page) I'm in? What is this link referring to? What other operations apart from GET can I execute with it? Can I add query parameters to it? What media type will it return? What media type may it expect if I can issue a POST?, etc...
          >
          > 2. rel is an attribute to add more information about a link. I denotes a value, keyword, hint of what relation the link has with the current resource/IRI. Say you are in a book page, that is your current resources and it has a URI. A link with rel="next" will hint that following that link will get you to the next page of the book.
          >
          > 3. It is important to understand that the rel is the relation the resource identified by the link's URI, has with the actual resource/uri/document. It is not good if you use rel to denote other information, like saying rel="CreateWithPost" to hint the agent to use the link's URI with a POST to create something. That is not the intended use and it is a bad practice.
          >
          > 4. You may need actual business intelligence in your client. If you are looking at a blog comment, a rel="parent" will tell you the links points to the actual blog post. Having that information, you can start asking that parent for information, or even send a comment to it using POST operation. That is natural simply because much of this interaction is already designed in the specs, and the agent may not need to be statically programmed, but it will need intelligence.
          >
          > 5. So, you have there standard metainformation (like how to handle media types, the semantics of POST and PUT, the semantics or link and rel), etc. Plus, you have business specific semantics (the actual value of the rel may mean something applicable only to, say, banking applications). With that info you can program intelligent clients.
          >
          > 6. Finally, some other "link" tags like anchor and image are special links that have a standard meaning and established processing. If you found an <img> tag you automatically know that link is referring to an image, and if you are in HTML page in a browser, the supposed processing it to fetch that image with a GET and display it based on context and additional attributes. All that is told by the tag name, and everybody in the world knows it. So, links are difficult to understand at first but once you have it clear they are simple to use. Only don't expect the link rel attribute will tell you everything.
          >
          > Cheers
          >
          > William Martinez.
          > --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@> wrote:
          > >
          > >
          > > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
          > > >
          > > > I know one of the first questions i had was on rel link. I understand the basic premise behind rel attributes(to provide a general documentation for how to interact with the link provider).
          > >
          > > The premise of the rel attribute on links is (in the case of the HTML or Atom media types) to provide information about the meaning of the link beyond 'this is a link'. If you register your rel name in the IANA registry, you can use the short name you registered, e.g. 'next' or 'up'. If you did not register your rel, you need to provide a URI. Simply for the matter of making your rel unambiguous.
          > >
          > > If that URI points to a human readable page explaining the relation, then that is even better.
          > >
          > > There is no magic (not even in REST :-) that removes the need to implement in code (or configure) what the user agent should do when it sees your link rel value.
          > >
          > > <link rel="http://foo/customerDetails" ... /> is conceptually the same as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or AtomPub's <collection href="..."/>. It is just hypermedia ... that a user agent needs to be programmed to do something with ... in order to have it do something with it.
          > >
          > > IOW, your browser downloads that image because it is programmed to do so. This same concept also applies to other hypermedia - your user agent component will act on the hypermedia it comes across in the way it is programmed (or configured) to do.
          > >
          > > No magic.
          > >
          > > The effect of the hypermedia constraint is actually more felt in the obligations you have as a client side programmer (to react to the hypermedia you actually come across instead of the one you presume to come across) than it is felt in the aspect of loose coupling.
          > >
          > > REST mostly makes explicit that there isn't any control over the server side in networked systems. REST encourages you to deal with that rather than magically solves a problem that cannot be solved. And on top of that, REST provides a number of mechanism that optimize for *dealing with* the problem (e.g. content negotiation).
          > >
          > > HTH,
          > >
          > > Jan
          > >
          > > > The question is what would you see if you go to the rel link? Is it something a person is suppose to interact with (say to get documentation for new links added to a specific response) or something code can interact with to determine what it needs to do? Unfortunately in the book they don't give an example of what a "rel" page would look like. For example the link:
          > > > <link rel="http://relations.restbucks.com/payment"
          > > > href:="http://restbucks.com/payment/1234" />
          > > >
          > > > If you typed in "http://relations.restbucks.com/payment" into your web browser what would you see?
          > > >
          > > > thanks...
          > > >
          > > >
          > >
          >


        • Rushforth, Peter
          Hi Paul, ... Fair enough, I did not go back to the spec to quote it, but throw GET in there too. ... How did you get here in the first place? When this
          Message 4 of 23 , May 4, 2012
          • 0 Attachment
            Hi Paul,

            > So, actually 'edit' means GET, PUT, DELETE (in at least one context :-).
            Fair enough, I did not go back to the spec to quote it, but throw GET in there too.

            >We could have a conversation about what 'self' means (a restatement of GET?), but let's park that for a moment.
            How did you get here in the first place? When this representation is taken out of its habitat,
            what is it/where did it come from/how can I get a fresh copy?

            > This is (at best) annoying for a user-agent which has to either (i) understand the completeness of the member entry in the feed - for which I see no mechanism to determine, or

            remember that the collection resource is not the member resource. So while a feed informs you of its members, it does not guarantee that the entries are complete. That is REST for you - no guarantees that the representation is the resource. And anyway, you haven't done a GET on the Member resource, just the Collection, so any Allow header you have received to date is about the Collection resource.

            > (ii) must always execute a GET, PUT cycle to make a change. If a GET is required anyway, there are other standard mechanisms to inform the user-agent of the permitted methods (e.g. 'Allow' header).
            Well of course you would want to do a GET before doing a PUT, unless you don't care what the resource says. You have a point with Allow, I think. I think you are arguing that a hypermedia format definition should associate method,rel,type "coordinates". Am I wrong?

            Cheers,
            Peter
          • Jørn Wildt
            ... I would say that you can do rel= CreateWithPost and declare that in the link-rel documentation. But you loose something by doing so: allowing the server
            Message 5 of 23 , May 4, 2012
            • 0 Attachment
              > > It is not good if you use rel to denote other information,
              > > like saying rel="CreateWithPost" to hint the agent to
              > > use the link's URI with a POST to create something.
              > > That is not the intended use and it is a bad practice.

              > It seems reasonable to me, I don't see why it is a bad practice.
              > It looks a lot like the atom:link@rel="edit", or html's @method="POST".

              I would say that you can do rel="CreateWithPost" and declare that in the
              link-rel documentation. But you loose something by doing so: allowing the
              server to specify HTTP method and payload encoding at runtime (since that
              knowledge would have to be a hardcoded part of the link-rel knowledge).

              Had the link "Create" instead lead to a form of some kind then the form
              could specifiy HTTP method at runtime, thus letting the server evolve over
              time (changing HTTP method) without updating the clients (as they are
              expected to understand the full form language).

              I haved tried to illustrate this in
              https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
              check the "evolving server, stable client" scenarios in example 1, 2 and 3.

              /Jørn

              ----- Original Message -----
              From: Rushforth, Peter
              To: paul_k_moore
              Cc: rest-discuss@yahoogroups.com
              Sent: Friday, May 04, 2012 2:28 PM
              Subject: RE: [rest-discuss] Re: Rel attributes?



              Hi Paul,

              In atompub, the rel="edit" link relation means you can PUT or DELETE to the
              href.

              Also in atompub, app:collection/accept/text() tells you you can POST the
              app:collection/@href whatever MIME types are
              listed in the app:accept text().

              Going by that as an exemplar, it seems to me that it is the hypermedia
              format which is defining what can and can't be
              done against the URL. Maybe that is out of band knowledge, but then again,
              knowing what @method="POST" means
              could be considered out of band too. It has to be written down somewhere
              and agreed to. So the sharing of the semantics
              widely is key to interoperability. Hence a public link relations registry.
              It is the shared semantics that allows us to
              program user agents to do predictable things when they come across a
              particular hypermedia construct.

              Maybe it is important that when a GET is done on a resource, that the
              response metadata also declare the available methods.
              Message metadata is authoritative.

              But you should not have to do that GET, because it is a waste of bandwidth,
              and the representation format has already
              defined (in the registry) and declared (in the instance in which you find
              the href) the (possibly implicit) method availabilities.

              > 3. It is important to understand that the rel is the relation the resource
              > identified by the link's URI, has with the actual resource/uri/document.
              > It is not good if you use rel to denote other information, like saying
              > rel="CreateWithPost" to hint the agent to use the link's URI with a POST
              > to create something. That is not the intended use and it is a bad
              > practice.

              It seems reasonable to me, I don't see why it is a bad practice. It looks a
              lot like the atom:link@rel="edit", or html's @method="POST".

              Cheers,
              Peter





              From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
              Behalf Of paul_k_moore
              Sent: May 3, 2012 11:00
              To: rest-discuss@yahoogroups.com
              Subject: [rest-discuss] Re: Rel attributes?





              William

              This is very useful - thank you.

              Just to confirm my (refined) understanding here, I consider the meaning of
              'rel' to be an orthogonal concern to the HTTP methods.

              To expound slightly, I had erroneously conflated the HTTP methods (avaialble
              at the target URI) into the meaning of 'rel'. If we consider the following
              two examples:

              Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
              reasonably conveys to the user-agent that there is something 'order'-like at
              the target URI. It is then up to the client (the client intent) to follow
              this rel (using an implicit GET request) to retrieve the representation of
              the 'order'-like thing (as rendered in a specific media-type).

              Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
              (unreasonably) convey that the user agent can POST an item of the type
              communicated by it's current context. This is the problem, I don't need to
              'say' to the user-agent that it can POST at a specific URI, because the
              available HTTP methods tell me what I can do with the resource. What I need
              to do is examine the permitted methods (either by inspection of the 'Allow'
              header, or an OPTIONS request) AND not try to convey the permutations of
              method in the 'rel'.

              Does that make sense?

              Thanks in advance

              Paul

              --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
              <wmartinez@...> wrote:
              >
              > Hi nikonguy74!
              > Just to complement what Jan is saying:
              > 1. Links represent resources you can work with. The idea of links is that
              > you can usually follow them (issuing a GET operation), but then there are
              > lots of questions you may have about them: what do I do with the actual
              > resource (say, web page) I'm in? What is this link referring to? What
              > other operations apart from GET can I execute with it? Can I add query
              > parameters to it? What media type will it return? What media type may it
              > expect if I can issue a POST?, etc...
              >
              > 2. rel is an attribute to add more information about a link. I denotes a
              > value, keyword, hint of what relation the link has with the current
              > resource/IRI. Say you are in a book page, that is your current resources
              > and it has a URI. A link with rel="next" will hint that following that
              > link will get you to the next page of the book.
              >
              > 3. It is important to understand that the rel is the relation the resource
              > identified by the link's URI, has with the actual resource/uri/document.
              > It is not good if you use rel to denote other information, like saying
              > rel="CreateWithPost" to hint the agent to use the link's URI with a POST
              > to create something. That is not the intended use and it is a bad
              > practice.
              >
              > 4. You may need actual business intelligence in your client. If you are
              > looking at a blog comment, a rel="parent" will tell you the links points
              > to the actual blog post. Having that information, you can start asking
              > that parent for information, or even send a comment to it using POST
              > operation. That is natural simply because much of this interaction is
              > already designed in the specs, and the agent may not need to be statically
              > programmed, but it will need intelligence.
              >
              > 5. So, you have there standard metainformation (like how to handle media
              > types, the semantics of POST and PUT, the semantics or link and rel), etc.
              > Plus, you have business specific semantics (the actual value of the rel
              > may mean something applicable only to, say, banking applications). With
              > that info you can program intelligent clients.
              >
              > 6. Finally, some other "link" tags like anchor and image are special links
              > that have a standard meaning and established processing. If you found an
              > <img> tag you automatically know that link is referring to an image, and
              > if you are in HTML page in a browser, the supposed processing it to fetch
              > that image with a GET and display it based on context and additional
              > attributes. All that is told by the tag name, and everybody in the world
              > knows it. So, links are difficult to understand at first but once you have
              > it clear they are simple to use. Only don't expect the link rel attribute
              > will tell you everything.
              >
              > Cheers
              >
              > William Martinez.
              > --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
              > wrote:
              > >
              > >
              > > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
              > > >
              > > > I know one of the first questions i had was on rel link. I understand
              > > > the basic premise behind rel attributes(to provide a general
              > > > documentation for how to interact with the link provider).
              > >
              > > The premise of the rel attribute on links is (in the case of the HTML or
              > > Atom media types) to provide information about the meaning of the link
              > > beyond 'this is a link'. If you register your rel name in the IANA
              > > registry, you can use the short name you registered, e.g. 'next' or
              > > 'up'. If you did not register your rel, you need to provide a URI.
              > > Simply for the matter of making your rel unambiguous.
              > >
              > > If that URI points to a human readable page explaining the relation,
              > > then that is even better.
              > >
              > > There is no magic (not even in REST :-) that removes the need to
              > > implement in code (or configure) what the user agent should do when it
              > > sees your link rel value.
              > >
              > > <link rel="http://foo/customerDetails" ... /> is conceptually the same
              > > as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
              > > AtomPub's <collection href="..."/>. It is just hypermedia ... that a
              > > user agent needs to be programmed to do something with ... in order to
              > > have it do something with it.
              > >
              > > IOW, your browser downloads that image because it is programmed to do
              > > so. This same concept also applies to other hypermedia - your user agent
              > > component will act on the hypermedia it comes across in the way it is
              > > programmed (or configured) to do.
              > >
              > > No magic.
              > >
              > > The effect of the hypermedia constraint is actually more felt in the
              > > obligations you have as a client side programmer (to react to the
              > > hypermedia you actually come across instead of the one you presume to
              > > come across) than it is felt in the aspect of loose coupling.
              > >
              > > REST mostly makes explicit that there isn't any control over the server
              > > side in networked systems. REST encourages you to deal with that rather
              > > than magically solves a problem that cannot be solved. And on top of
              > > that, REST provides a number of mechanism that optimize for *dealing
              > > with* the problem (e.g. content negotiation).
              > >
              > > HTH,
              > >
              > > Jan
              > >
              > > > The question is what would you see if you go to the rel link? Is it
              > > > something a person is suppose to interact with (say to get
              > > > documentation for new links added to a specific response) or something
              > > > code can interact with to determine what it needs to do? Unfortunately
              > > > in the book they don't give an example of what a "rel" page would look
              > > > like. For example the link:
              > > > <link rel="http://relations.restbucks.com/payment"
              > > > href:="http://restbucks.com/payment/1234" />
              > > >
              > > > If you typed in "http://relations.restbucks.com/payment" into your web
              > > > browser what would you see?
              > > >
              > > > thanks...
              > > >
              > > >
              > >
              >
            • mike amundsen
              Jørn, Paul, Peter: here are two options for a hypermedia affordances in a media type design that supports writing new and updating existing resources:
              Message 6 of 23 , May 4, 2012
              • 0 Attachment
                Jørn, Paul, Peter:

                here are two options for a hypermedia affordances in a media type
                design that supports writing new and updating existing resources:

                <create href="..." >...</create>
                <update href="...">...</update>
                OR
                <write href="..." action="create">...</write>
                <write href="..." action="update">...</write>

                Which relies on more "out-of-band" knowledge?
                Which is a "better" design and why?

                mca
                http://amundsen.com/blog/
                http://twitter.com@mamund
                http://mamund.com/foaf.rdf#me



                On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                >> > It is not good if you use rel to denote other information,
                >> > like saying rel="CreateWithPost" to hint the agent to
                >> > use the link's URI with a POST to create something.
                >> > That is not the intended use and it is a bad practice.
                >
                >> It seems reasonable to me, I don't see why it is a bad practice.
                >> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                >
                > I would say that you can do rel="CreateWithPost" and declare that in the
                > link-rel documentation. But you loose something by doing so: allowing the
                > server to specify HTTP method and payload encoding at runtime (since that
                > knowledge would have to be a hardcoded part of the link-rel knowledge).
                >
                > Had the link "Create" instead lead to a form of some kind then the form
                > could specifiy HTTP method at runtime, thus letting the server evolve over
                > time (changing HTTP method) without updating the clients (as they are
                > expected to understand the full form language).
                >
                > I haved tried to illustrate this in
                > https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                > check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                >
                > /Jørn
                >
                > ----- Original Message -----
                > From: Rushforth, Peter
                > To: paul_k_moore
                > Cc: rest-discuss@yahoogroups.com
                > Sent: Friday, May 04, 2012 2:28 PM
                > Subject: RE: [rest-discuss] Re: Rel attributes?
                >
                >
                >
                > Hi Paul,
                >
                > In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                > href.
                >
                > Also in atompub, app:collection/accept/text() tells you you can POST the
                > app:collection/@href whatever MIME types are
                > listed in the app:accept text().
                >
                > Going by that as an exemplar, it seems to me that it is the hypermedia
                > format which is defining what can and can't be
                > done against the URL.  Maybe that is out of band knowledge, but then again,
                > knowing what @method="POST" means
                > could be considered out of band too.   It has to be written down somewhere
                > and agreed to.  So the sharing of the semantics
                > widely is key to interoperability.  Hence a public link relations registry.
                > It is the shared semantics that allows us to
                > program user agents to do predictable things when they come across a
                > particular hypermedia construct.
                >
                > Maybe it is important that when a GET is done on a resource, that the
                > response metadata also declare the available methods.
                > Message metadata is authoritative.
                >
                > But you should not have to do that GET, because it is a waste of bandwidth,
                > and the representation format has already
                > defined (in the registry) and declared (in the instance in which you find
                > the href) the (possibly implicit) method availabilities.
                >
                >> 3. It is important to understand that the rel is the relation the resource
                >> identified by the link's URI, has with the actual resource/uri/document.
                >> It is not good if you use rel to denote other information, like saying
                >> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                >> to create something. That is not the intended use and it is a bad
                >> practice.
                >
                > It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                > lot like the atom:link@rel="edit", or html's @method="POST".
                >
                > Cheers,
                > Peter
                >
                >
                >
                >
                >
                > From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                > Behalf Of paul_k_moore
                > Sent: May 3, 2012 11:00
                > To: rest-discuss@yahoogroups.com
                > Subject: [rest-discuss] Re: Rel attributes?
                >
                >
                >
                >
                >
                > William
                >
                > This is very useful - thank you.
                >
                > Just to confirm my (refined) understanding here, I consider the meaning of
                > 'rel' to be an orthogonal concern to the HTTP methods.
                >
                > To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                > at the target URI) into the meaning of 'rel'. If we consider the following
                > two examples:
                >
                > Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                > reasonably conveys to the user-agent that there is something 'order'-like at
                > the target URI. It is then up to the client (the client intent) to follow
                > this rel (using an implicit GET request) to retrieve the representation of
                > the 'order'-like thing (as rendered in a specific media-type).
                >
                > Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                > (unreasonably) convey that the user agent can POST an item of the type
                > communicated by it's current context. This is the problem, I don't need to
                > 'say' to the user-agent that it can POST at a specific URI, because the
                > available HTTP methods tell me what I can do with the resource. What I need
                > to do is examine the permitted methods (either by inspection of the 'Allow'
                > header, or an OPTIONS request) AND not try to convey the permutations of
                > method in the 'rel'.
                >
                > Does that make sense?
                >
                > Thanks in advance
                >
                > Paul
                >
                > --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                > <wmartinez@...> wrote:
                >>
                >> Hi nikonguy74!
                >> Just to complement what Jan is saying:
                >> 1. Links represent resources you can work with. The idea of links is that
                >> you can usually follow them (issuing a GET operation), but then there are
                >> lots of questions you may have about them: what do I do with the actual
                >> resource (say, web page) I'm in? What is this link referring to? What
                >> other operations apart from GET can I execute with it? Can I add query
                >> parameters to it? What media type will it return? What media type may it
                >> expect if I can issue a POST?, etc...
                >>
                >> 2. rel is an attribute to add more information about a link. I denotes a
                >> value, keyword, hint of what relation the link has with the current
                >> resource/IRI. Say you are in a book page, that is your current resources
                >> and it has a URI. A link with rel="next" will hint that following that
                >> link will get you to the next page of the book.
                >>
                >> 3. It is important to understand that the rel is the relation the resource
                >> identified by the link's URI, has with the actual resource/uri/document.
                >> It is not good if you use rel to denote other information, like saying
                >> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                >> to create something. That is not the intended use and it is a bad
                >> practice.
                >>
                >> 4. You may need actual business intelligence in your client. If you are
                >> looking at a blog comment, a rel="parent" will tell you the links points
                >> to the actual blog post. Having that information, you can start asking
                >> that parent for information, or even send a comment to it using POST
                >> operation. That is natural simply because much of this interaction is
                >> already designed in the specs, and the agent may not need to be statically
                >> programmed, but it will need intelligence.
                >>
                >> 5. So, you have there standard metainformation (like how to handle media
                >> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                >> Plus, you have business specific semantics (the actual value of the rel
                >> may mean something applicable only to, say, banking applications). With
                >> that info you can program intelligent clients.
                >>
                >> 6. Finally, some other "link" tags like anchor and image are special links
                >> that have a standard meaning and established processing. If you found an
                >> <img> tag you automatically know that link is referring to an image, and
                >> if you are in HTML page in a browser, the supposed processing it to fetch
                >> that image with a GET and display it based on context and additional
                >> attributes. All that is told by the tag name, and everybody in the world
                >> knows it. So, links are difficult to understand at first but once you have
                >> it clear they are simple to use. Only don't expect the link rel attribute
                >> will tell you everything.
                >>
                >> Cheers
                >>
                >> William Martinez.
                >> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                >> wrote:
                >> >
                >> >
                >> > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                >> > >
                >> > > I know one of the first questions i had was on rel link. I understand
                >> > > the basic premise behind rel attributes(to provide a general
                >> > > documentation for how to interact with the link provider).
                >> >
                >> > The premise of the rel attribute on links is (in the case of the HTML or
                >> > Atom media types) to provide information about the meaning of the link
                >> > beyond 'this is a link'. If you register your rel name in the IANA
                >> > registry, you can use the short name you registered, e.g. 'next' or
                >> > 'up'. If you did not register your rel, you need to provide a URI.
                >> > Simply for the matter of making your rel unambiguous.
                >> >
                >> > If that URI points to a human readable page explaining the relation,
                >> > then that is even better.
                >> >
                >> > There is no magic (not even in REST :-) that removes the need to
                >> > implement in code (or configure) what the user agent should do when it
                >> > sees your link rel value.
                >> >
                >> > <link rel="http://foo/customerDetails" ... /> is conceptually the same
                >> > as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                >> > AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                >> > user agent needs to be programmed to do something with ... in order to
                >> > have it do something with it.
                >> >
                >> > IOW, your browser downloads that image because it is programmed to do
                >> > so. This same concept also applies to other hypermedia - your user agent
                >> > component will act on the hypermedia it comes across in the way it is
                >> > programmed (or configured) to do.
                >> >
                >> > No magic.
                >> >
                >> > The effect of the hypermedia constraint is actually more felt in the
                >> > obligations you have as a client side programmer (to react to the
                >> > hypermedia you actually come across instead of the one you presume to
                >> > come across) than it is felt in the aspect of loose coupling.
                >> >
                >> > REST mostly makes explicit that there isn't any control over the server
                >> > side in networked systems. REST encourages you to deal with that rather
                >> > than magically solves a problem that cannot be solved. And on top of
                >> > that, REST provides a number of mechanism that optimize for *dealing
                >> > with* the problem (e.g. content negotiation).
                >> >
                >> > HTH,
                >> >
                >> > Jan
                >> >
                >> > > The question is what would you see if you go to the rel link? Is it
                >> > > something a person is suppose to interact with (say to get
                >> > > documentation for new links added to a specific response) or something
                >> > > code can interact with to determine what it needs to do? Unfortunately
                >> > > in the book they don't give an example of what a "rel" page would look
                >> > > like. For example the link:
                >> > > <link rel="http://relations.restbucks.com/payment"
                >> > > href:="http://restbucks.com/payment/1234" />
                >> > >
                >> > > If you typed in "http://relations.restbucks.com/payment" into your web
                >> > > browser what would you see?
                >> > >
                >> > > thanks...
                >> > >
                >> > >
                >> >
                >>
                >
                >
                >
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
              • Jorn Wildt
                Both examples allows the server to add new elements without breaking existing clients so both are fine with me. New clients has to look for new stuff anyway -
                Message 7 of 23 , May 5, 2012
                • 0 Attachment
                  Both examples allows the server to add new elements without breaking existing clients so both are fine with me. New clients has to look for new stuff anyway - be it as new elements or as new actions/relations. So the same amount of out-of-band knowledge seems to be required.

                  Personally I prefer the generic <write> since the client won't have to add new parsing capabilities if it already supports collections of named <write> elements.

                  /Jørn


                  --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                  >
                  > Jørn, Paul, Peter:
                  >
                  > here are two options for a hypermedia affordances in a media type
                  > design that supports writing new and updating existing resources:
                  >
                  > <create href="..." >...</create>
                  > <update href="...">...</update>
                  > OR
                  > <write href="..." action="create">...</write>
                  > <write href="..." action="update">...</write>
                  >
                  > Which relies on more "out-of-band" knowledge?
                  > Which is a "better" design and why?
                  >
                  > mca
                  > http://amundsen.com/blog/
                  > http://twitter.com@mamund
                  > http://mamund.com/foaf.rdf#me
                  >
                • Jakob Strauch
                  Hi Mike, i guess the second design is easier to evolve by defining more valid action values without breaking the client, which can ignore unknown actions. As
                  Message 8 of 23 , May 5, 2012
                  • 0 Attachment
                    Hi Mike,

                    i guess the second design is easier to evolve by defining more valid action values without breaking the client, which can ignore unknown actions.

                    As far as i can see, the out of band knowledge is pretty much the same, isn´t it?

                    Jakob

                    --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                    >
                    > Jørn, Paul, Peter:
                    >
                    > here are two options for a hypermedia affordances in a media type
                    > design that supports writing new and updating existing resources:
                    >
                    > <create href="..." >...</create>
                    > <update href="...">...</update>
                    > OR
                    > <write href="..." action="create">...</write>
                    > <write href="..." action="update">...</write>
                    >
                    > Which relies on more "out-of-band" knowledge?
                    > Which is a "better" design and why?
                    >
                    > mca
                    > http://amundsen.com/blog/
                    > http://twitter.com@mamund
                    > http://mamund.com/foaf.rdf#me
                    >
                    >
                    >
                    > On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                    > >> > It is not good if you use rel to denote other information,
                    > >> > like saying rel="CreateWithPost" to hint the agent to
                    > >> > use the link's URI with a POST to create something.
                    > >> > That is not the intended use and it is a bad practice.
                    > >
                    > >> It seems reasonable to me, I don't see why it is a bad practice.
                    > >> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                    > >
                    > > I would say that you can do rel="CreateWithPost" and declare that in the
                    > > link-rel documentation. But you loose something by doing so: allowing the
                    > > server to specify HTTP method and payload encoding at runtime (since that
                    > > knowledge would have to be a hardcoded part of the link-rel knowledge).
                    > >
                    > > Had the link "Create" instead lead to a form of some kind then the form
                    > > could specifiy HTTP method at runtime, thus letting the server evolve over
                    > > time (changing HTTP method) without updating the clients (as they are
                    > > expected to understand the full form language).
                    > >
                    > > I haved tried to illustrate this in
                    > > https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                    > > check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                    > >
                    > > /Jørn
                    > >
                    > > ----- Original Message -----
                    > > From: Rushforth, Peter
                    > > To: paul_k_moore
                    > > Cc: rest-discuss@yahoogroups.com
                    > > Sent: Friday, May 04, 2012 2:28 PM
                    > > Subject: RE: [rest-discuss] Re: Rel attributes?
                    > >
                    > >
                    > >
                    > > Hi Paul,
                    > >
                    > > In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                    > > href.
                    > >
                    > > Also in atompub, app:collection/accept/text() tells you you can POST the
                    > > app:collection/@href whatever MIME types are
                    > > listed in the app:accept text().
                    > >
                    > > Going by that as an exemplar, it seems to me that it is the hypermedia
                    > > format which is defining what can and can't be
                    > > done against the URL.  Maybe that is out of band knowledge, but then again,
                    > > knowing what @method="POST" means
                    > > could be considered out of band too.   It has to be written down somewhere
                    > > and agreed to.  So the sharing of the semantics
                    > > widely is key to interoperability.  Hence a public link relations registry.
                    > > It is the shared semantics that allows us to
                    > > program user agents to do predictable things when they come across a
                    > > particular hypermedia construct.
                    > >
                    > > Maybe it is important that when a GET is done on a resource, that the
                    > > response metadata also declare the available methods.
                    > > Message metadata is authoritative.
                    > >
                    > > But you should not have to do that GET, because it is a waste of bandwidth,
                    > > and the representation format has already
                    > > defined (in the registry) and declared (in the instance in which you find
                    > > the href) the (possibly implicit) method availabilities.
                    > >
                    > >> 3. It is important to understand that the rel is the relation the resource
                    > >> identified by the link's URI, has with the actual resource/uri/document.
                    > >> It is not good if you use rel to denote other information, like saying
                    > >> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                    > >> to create something. That is not the intended use and it is a bad
                    > >> practice.
                    > >
                    > > It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                    > > lot like the atom:link@rel="edit", or html's @method="POST".
                    > >
                    > > Cheers,
                    > > Peter
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                    > > Behalf Of paul_k_moore
                    > > Sent: May 3, 2012 11:00
                    > > To: rest-discuss@yahoogroups.com
                    > > Subject: [rest-discuss] Re: Rel attributes?
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > William
                    > >
                    > > This is very useful - thank you.
                    > >
                    > > Just to confirm my (refined) understanding here, I consider the meaning of
                    > > 'rel' to be an orthogonal concern to the HTTP methods.
                    > >
                    > > To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                    > > at the target URI) into the meaning of 'rel'. If we consider the following
                    > > two examples:
                    > >
                    > > Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                    > > reasonably conveys to the user-agent that there is something 'order'-like at
                    > > the target URI. It is then up to the client (the client intent) to follow
                    > > this rel (using an implicit GET request) to retrieve the representation of
                    > > the 'order'-like thing (as rendered in a specific media-type).
                    > >
                    > > Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                    > > (unreasonably) convey that the user agent can POST an item of the type
                    > > communicated by it's current context. This is the problem, I don't need to
                    > > 'say' to the user-agent that it can POST at a specific URI, because the
                    > > available HTTP methods tell me what I can do with the resource. What I need
                    > > to do is examine the permitted methods (either by inspection of the 'Allow'
                    > > header, or an OPTIONS request) AND not try to convey the permutations of
                    > > method in the 'rel'.
                    > >
                    > > Does that make sense?
                    > >
                    > > Thanks in advance
                    > >
                    > > Paul
                    > >
                    > > --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                    > > <wmartinez@> wrote:
                    > >>
                    > >> Hi nikonguy74!
                    > >> Just to complement what Jan is saying:
                    > >> 1. Links represent resources you can work with. The idea of links is that
                    > >> you can usually follow them (issuing a GET operation), but then there are
                    > >> lots of questions you may have about them: what do I do with the actual
                    > >> resource (say, web page) I'm in? What is this link referring to? What
                    > >> other operations apart from GET can I execute with it? Can I add query
                    > >> parameters to it? What media type will it return? What media type may it
                    > >> expect if I can issue a POST?, etc...
                    > >>
                    > >> 2. rel is an attribute to add more information about a link. I denotes a
                    > >> value, keyword, hint of what relation the link has with the current
                    > >> resource/IRI. Say you are in a book page, that is your current resources
                    > >> and it has a URI. A link with rel="next" will hint that following that
                    > >> link will get you to the next page of the book.
                    > >>
                    > >> 3. It is important to understand that the rel is the relation the resource
                    > >> identified by the link's URI, has with the actual resource/uri/document.
                    > >> It is not good if you use rel to denote other information, like saying
                    > >> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                    > >> to create something. That is not the intended use and it is a bad
                    > >> practice.
                    > >>
                    > >> 4. You may need actual business intelligence in your client. If you are
                    > >> looking at a blog comment, a rel="parent" will tell you the links points
                    > >> to the actual blog post. Having that information, you can start asking
                    > >> that parent for information, or even send a comment to it using POST
                    > >> operation. That is natural simply because much of this interaction is
                    > >> already designed in the specs, and the agent may not need to be statically
                    > >> programmed, but it will need intelligence.
                    > >>
                    > >> 5. So, you have there standard metainformation (like how to handle media
                    > >> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                    > >> Plus, you have business specific semantics (the actual value of the rel
                    > >> may mean something applicable only to, say, banking applications). With
                    > >> that info you can program intelligent clients.
                    > >>
                    > >> 6. Finally, some other "link" tags like anchor and image are special links
                    > >> that have a standard meaning and established processing. If you found an
                    > >> <img> tag you automatically know that link is referring to an image, and
                    > >> if you are in HTML page in a browser, the supposed processing it to fetch
                    > >> that image with a GET and display it based on context and additional
                    > >> attributes. All that is told by the tag name, and everybody in the world
                    > >> knows it. So, links are difficult to understand at first but once you have
                    > >> it clear they are simple to use. Only don't expect the link rel attribute
                    > >> will tell you everything.
                    > >>
                    > >> Cheers
                    > >>
                    > >> William Martinez.
                    > >> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                    > >> wrote:
                    > >> >
                    > >> >
                    > >> > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                    > >> > >
                    > >> > > I know one of the first questions i had was on rel link. I understand
                    > >> > > the basic premise behind rel attributes(to provide a general
                    > >> > > documentation for how to interact with the link provider).
                    > >> >
                    > >> > The premise of the rel attribute on links is (in the case of the HTML or
                    > >> > Atom media types) to provide information about the meaning of the link
                    > >> > beyond 'this is a link'. If you register your rel name in the IANA
                    > >> > registry, you can use the short name you registered, e.g. 'next' or
                    > >> > 'up'. If you did not register your rel, you need to provide a URI.
                    > >> > Simply for the matter of making your rel unambiguous.
                    > >> >
                    > >> > If that URI points to a human readable page explaining the relation,
                    > >> > then that is even better.
                    > >> >
                    > >> > There is no magic (not even in REST :-) that removes the need to
                    > >> > implement in code (or configure) what the user agent should do when it
                    > >> > sees your link rel value.
                    > >> >
                    > >> > <link rel="http://foo/customerDetails" ... /> is conceptually the same
                    > >> > as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                    > >> > AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                    > >> > user agent needs to be programmed to do something with ... in order to
                    > >> > have it do something with it.
                    > >> >
                    > >> > IOW, your browser downloads that image because it is programmed to do
                    > >> > so. This same concept also applies to other hypermedia - your user agent
                    > >> > component will act on the hypermedia it comes across in the way it is
                    > >> > programmed (or configured) to do.
                    > >> >
                    > >> > No magic.
                    > >> >
                    > >> > The effect of the hypermedia constraint is actually more felt in the
                    > >> > obligations you have as a client side programmer (to react to the
                    > >> > hypermedia you actually come across instead of the one you presume to
                    > >> > come across) than it is felt in the aspect of loose coupling.
                    > >> >
                    > >> > REST mostly makes explicit that there isn't any control over the server
                    > >> > side in networked systems. REST encourages you to deal with that rather
                    > >> > than magically solves a problem that cannot be solved. And on top of
                    > >> > that, REST provides a number of mechanism that optimize for *dealing
                    > >> > with* the problem (e.g. content negotiation).
                    > >> >
                    > >> > HTH,
                    > >> >
                    > >> > Jan
                    > >> >
                    > >> > > The question is what would you see if you go to the rel link? Is it
                    > >> > > something a person is suppose to interact with (say to get
                    > >> > > documentation for new links added to a specific response) or something
                    > >> > > code can interact with to determine what it needs to do? Unfortunately
                    > >> > > in the book they don't give an example of what a "rel" page would look
                    > >> > > like. For example the link:
                    > >> > > <link rel="http://relations.restbucks.com/payment"
                    > >> > > href:="http://restbucks.com/payment/1234" />
                    > >> > >
                    > >> > > If you typed in "http://relations.restbucks.com/payment" into your web
                    > >> > > browser what would you see?
                    > >> > >
                    > >> > > thanks...
                    > >> > >
                    > >> > >
                    > >> >
                    > >>
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > ------------------------------------
                    > >
                    > > Yahoo! Groups Links
                    > >
                    > >
                    > >
                    >
                  • Rushforth, Peter
                    Hi Mike, A couple of my replies through the yahoo web interface have gone awol. Thanks for this. Both rely on the hypermedia documentation, per Roy s
                    Message 9 of 23 , May 5, 2012
                    • 0 Attachment
                      Hi Mike,

                      A couple of my replies through the yahoo web interface have gone awol.

                      Thanks for this.

                      Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
                      The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.

                      Cheers,
                      Peter
                      ________________________________________
                      From: mca@... [mca@...] on behalf of mike amundsen [mamund@...]
                      Sent: May 5, 2012 1:04 AM
                      To: Jørn Wildt
                      Cc: paul_k_moore; Rushforth, Peter; rest-discuss@yahoogroups.com
                      Subject: Re: [rest-discuss] Re: Rel attributes?

                      Jørn, Paul, Peter:

                      here are two options for a hypermedia affordances in a media type
                      design that supports writing new and updating existing resources:

                      <create href="..." >...</create>
                      <update href="...">...</update>
                      OR
                      <write href="..." action="create">...</write>
                      <write href="..." action="update">...</write>

                      Which relies on more "out-of-band" knowledge?
                      Which is a "better" design and why?

                      mca
                      http://amundsen.com/blog/
                      http://twitter.com@mamund
                      http://mamund.com/foaf.rdf#me



                      On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                      >> > It is not good if you use rel to denote other information,
                      >> > like saying rel="CreateWithPost" to hint the agent to
                      >> > use the link's URI with a POST to create something.
                      >> > That is not the intended use and it is a bad practice.
                      >
                      >> It seems reasonable to me, I don't see why it is a bad practice.
                      >> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                      >
                      > I would say that you can do rel="CreateWithPost" and declare that in the
                      > link-rel documentation. But you loose something by doing so: allowing the
                      > server to specify HTTP method and payload encoding at runtime (since that
                      > knowledge would have to be a hardcoded part of the link-rel knowledge).
                      >
                      > Had the link "Create" instead lead to a form of some kind then the form
                      > could specifiy HTTP method at runtime, thus letting the server evolve over
                      > time (changing HTTP method) without updating the clients (as they are
                      > expected to understand the full form language).
                      >
                      > I haved tried to illustrate this in
                      > https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                      > check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                      >
                      > /Jørn
                      >
                      > ----- Original Message -----
                      > From: Rushforth, Peter
                      > To: paul_k_moore
                      > Cc: rest-discuss@yahoogroups.com
                      > Sent: Friday, May 04, 2012 2:28 PM
                      > Subject: RE: [rest-discuss] Re: Rel attributes?
                      >
                      >
                      >
                      > Hi Paul,
                      >
                      > In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                      > href.
                      >
                      > Also in atompub, app:collection/accept/text() tells you you can POST the
                      > app:collection/@href whatever MIME types are
                      > listed in the app:accept text().
                      >
                      > Going by that as an exemplar, it seems to me that it is the hypermedia
                      > format which is defining what can and can't be
                      > done against the URL. Maybe that is out of band knowledge, but then again,
                      > knowing what @method="POST" means
                      > could be considered out of band too. It has to be written down somewhere
                      > and agreed to. So the sharing of the semantics
                      > widely is key to interoperability. Hence a public link relations registry.
                      > It is the shared semantics that allows us to
                      > program user agents to do predictable things when they come across a
                      > particular hypermedia construct.
                      >
                      > Maybe it is important that when a GET is done on a resource, that the
                      > response metadata also declare the available methods.
                      > Message metadata is authoritative.
                      >
                      > But you should not have to do that GET, because it is a waste of bandwidth,
                      > and the representation format has already
                      > defined (in the registry) and declared (in the instance in which you find
                      > the href) the (possibly implicit) method availabilities.
                      >
                      >> 3. It is important to understand that the rel is the relation the resource
                      >> identified by the link's URI, has with the actual resource/uri/document.
                      >> It is not good if you use rel to denote other information, like saying
                      >> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                      >> to create something. That is not the intended use and it is a bad
                      >> practice.
                      >
                      > It seems reasonable to me, I don't see why it is a bad practice. It looks a
                      > lot like the atom:link@rel="edit", or html's @method="POST".
                      >
                      > Cheers,
                      > Peter
                      >
                      >
                      >
                      >
                      >
                      > From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                      > Behalf Of paul_k_moore
                      > Sent: May 3, 2012 11:00
                      > To: rest-discuss@yahoogroups.com
                      > Subject: [rest-discuss] Re: Rel attributes?
                      >
                      >
                      >
                      >
                      >
                      > William
                      >
                      > This is very useful - thank you.
                      >
                      > Just to confirm my (refined) understanding here, I consider the meaning of
                      > 'rel' to be an orthogonal concern to the HTTP methods.
                      >
                      > To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                      > at the target URI) into the meaning of 'rel'. If we consider the following
                      > two examples:
                      >
                      > Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                      > reasonably conveys to the user-agent that there is something 'order'-like at
                      > the target URI. It is then up to the client (the client intent) to follow
                      > this rel (using an implicit GET request) to retrieve the representation of
                      > the 'order'-like thing (as rendered in a specific media-type).
                      >
                      > Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                      > (unreasonably) convey that the user agent can POST an item of the type
                      > communicated by it's current context. This is the problem, I don't need to
                      > 'say' to the user-agent that it can POST at a specific URI, because the
                      > available HTTP methods tell me what I can do with the resource. What I need
                      > to do is examine the permitted methods (either by inspection of the 'Allow'
                      > header, or an OPTIONS request) AND not try to convey the permutations of
                      > method in the 'rel'.
                      >
                      > Does that make sense?
                      >
                      > Thanks in advance
                      >
                      > Paul
                      >
                      > --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                      > <wmartinez@...> wrote:
                      >>
                      >> Hi nikonguy74!
                      >> Just to complement what Jan is saying:
                      >> 1. Links represent resources you can work with. The idea of links is that
                      >> you can usually follow them (issuing a GET operation), but then there are
                      >> lots of questions you may have about them: what do I do with the actual
                      >> resource (say, web page) I'm in? What is this link referring to? What
                      >> other operations apart from GET can I execute with it? Can I add query
                      >> parameters to it? What media type will it return? What media type may it
                      >> expect if I can issue a POST?, etc...
                      >>
                      >> 2. rel is an attribute to add more information about a link. I denotes a
                      >> value, keyword, hint of what relation the link has with the current
                      >> resource/IRI. Say you are in a book page, that is your current resources
                      >> and it has a URI. A link with rel="next" will hint that following that
                      >> link will get you to the next page of the book.
                      >>
                      >> 3. It is important to understand that the rel is the relation the resource
                      >> identified by the link's URI, has with the actual resource/uri/document.
                      >> It is not good if you use rel to denote other information, like saying
                      >> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                      >> to create something. That is not the intended use and it is a bad
                      >> practice.
                      >>
                      >> 4. You may need actual business intelligence in your client. If you are
                      >> looking at a blog comment, a rel="parent" will tell you the links points
                      >> to the actual blog post. Having that information, you can start asking
                      >> that parent for information, or even send a comment to it using POST
                      >> operation. That is natural simply because much of this interaction is
                      >> already designed in the specs, and the agent may not need to be statically
                      >> programmed, but it will need intelligence.
                      >>
                      >> 5. So, you have there standard metainformation (like how to handle media
                      >> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                      >> Plus, you have business specific semantics (the actual value of the rel
                      >> may mean something applicable only to, say, banking applications). With
                      >> that info you can program intelligent clients.
                      >>
                      >> 6. Finally, some other "link" tags like anchor and image are special links
                      >> that have a standard meaning and established processing. If you found an
                      >> <img> tag you automatically know that link is referring to an image, and
                      >> if you are in HTML page in a browser, the supposed processing it to fetch
                      >> that image with a GET and display it based on context and additional
                      >> attributes. All that is told by the tag name, and everybody in the world
                      >> knows it. So, links are difficult to understand at first but once you have
                      >> it clear they are simple to use. Only don't expect the link rel attribute
                      >> will tell you everything.
                      >>
                      >> Cheers
                      >>
                      >> William Martinez.
                      >> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                      >> wrote:
                      >> >
                      >> >
                      >> > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                      >> > >
                      >> > > I know one of the first questions i had was on rel link. I understand
                      >> > > the basic premise behind rel attributes(to provide a general
                      >> > > documentation for how to interact with the link provider).
                      >> >
                      >> > The premise of the rel attribute on links is (in the case of the HTML or
                      >> > Atom media types) to provide information about the meaning of the link
                      >> > beyond 'this is a link'. If you register your rel name in the IANA
                      >> > registry, you can use the short name you registered, e.g. 'next' or
                      >> > 'up'. If you did not register your rel, you need to provide a URI.
                      >> > Simply for the matter of making your rel unambiguous.
                      >> >
                      >> > If that URI points to a human readable page explaining the relation,
                      >> > then that is even better.
                      >> >
                      >> > There is no magic (not even in REST :-) that removes the need to
                      >> > implement in code (or configure) what the user agent should do when it
                      >> > sees your link rel value.
                      >> >
                      >> > <link rel="http://foo/customerDetails" ... /> is conceptually the same
                      >> > as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                      >> > AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                      >> > user agent needs to be programmed to do something with ... in order to
                      >> > have it do something with it.
                      >> >
                      >> > IOW, your browser downloads that image because it is programmed to do
                      >> > so. This same concept also applies to other hypermedia - your user agent
                      >> > component will act on the hypermedia it comes across in the way it is
                      >> > programmed (or configured) to do.
                      >> >
                      >> > No magic.
                      >> >
                      >> > The effect of the hypermedia constraint is actually more felt in the
                      >> > obligations you have as a client side programmer (to react to the
                      >> > hypermedia you actually come across instead of the one you presume to
                      >> > come across) than it is felt in the aspect of loose coupling.
                      >> >
                      >> > REST mostly makes explicit that there isn't any control over the server
                      >> > side in networked systems. REST encourages you to deal with that rather
                      >> > than magically solves a problem that cannot be solved. And on top of
                      >> > that, REST provides a number of mechanism that optimize for *dealing
                      >> > with* the problem (e.g. content negotiation).
                      >> >
                      >> > HTH,
                      >> >
                      >> > Jan
                      >> >
                      >> > > The question is what would you see if you go to the rel link? Is it
                      >> > > something a person is suppose to interact with (say to get
                      >> > > documentation for new links added to a specific response) or something
                      >> > > code can interact with to determine what it needs to do? Unfortunately
                      >> > > in the book they don't give an example of what a "rel" page would look
                      >> > > like. For example the link:
                      >> > > <link rel="http://relations.restbucks.com/payment"
                      >> > > href:="http://restbucks.com/payment/1234" />
                      >> > >
                      >> > > If you typed in "http://relations.restbucks.com/payment" into your web
                      >> > > browser what would you see?
                      >> > >
                      >> > > thanks...
                      >> > >
                      >> > >
                      >> >
                      >>
                      >
                      >
                      >
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                    • mike amundsen
                      note that neither option contains: http method or encoding information. that is out of band knowledge in these designs. is that good or bad here? mca
                      Message 10 of 23 , May 5, 2012
                      • 0 Attachment
                        note that neither option contains: http method or encoding information.

                        that is "out of band" knowledge in these designs.

                        is that "good" or "bad" here?

                        mca
                        http://amundsen.com/blog/
                        http://twitter.com@mamund
                        http://mamund.com/foaf.rdf#me



                        On Sat, May 5, 2012 at 6:26 AM, Rushforth, Peter
                        <peter.rushforth@...> wrote:
                        > Hi Mike,
                        >
                        > A couple of my replies through the yahoo web interface have gone awol.
                        >
                        > Thanks for this.
                        >
                        > Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
                        > The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.
                        >
                        > Cheers,
                        > Peter
                        > ________________________________________
                        > From: mca@... [mca@...] on behalf of mike amundsen [mamund@...]
                        > Sent: May 5, 2012 1:04 AM
                        > To: Jørn Wildt
                        > Cc: paul_k_moore; Rushforth, Peter; rest-discuss@yahoogroups.com
                        > Subject: Re: [rest-discuss] Re: Rel attributes?
                        >
                        > Jørn, Paul, Peter:
                        >
                        > here are two options for a hypermedia affordances in a media type
                        > design that supports writing new and updating existing resources:
                        >
                        > <create href="..." >...</create>
                        > <update href="...">...</update>
                        > OR
                        > <write href="..." action="create">...</write>
                        > <write href="..." action="update">...</write>
                        >
                        > Which relies on more "out-of-band" knowledge?
                        > Which is a "better" design and why?
                        >
                        > mca
                        > http://amundsen.com/blog/
                        > http://twitter.com@mamund
                        > http://mamund.com/foaf.rdf#me
                        >
                        >
                        >
                        > On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                        >>> > It is not good if you use rel to denote other information,
                        >>> > like saying rel="CreateWithPost" to hint the agent to
                        >>> > use the link's URI with a POST to create something.
                        >>> > That is not the intended use and it is a bad practice.
                        >>
                        >>> It seems reasonable to me, I don't see why it is a bad practice.
                        >>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                        >>
                        >> I would say that you can do rel="CreateWithPost" and declare that in the
                        >> link-rel documentation. But you loose something by doing so: allowing the
                        >> server to specify HTTP method and payload encoding at runtime (since that
                        >> knowledge would have to be a hardcoded part of the link-rel knowledge).
                        >>
                        >> Had the link "Create" instead lead to a form of some kind then the form
                        >> could specifiy HTTP method at runtime, thus letting the server evolve over
                        >> time (changing HTTP method) without updating the clients (as they are
                        >> expected to understand the full form language).
                        >>
                        >> I haved tried to illustrate this in
                        >> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                        >> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                        >>
                        >> /Jørn
                        >>
                        >> ----- Original Message -----
                        >> From: Rushforth, Peter
                        >> To: paul_k_moore
                        >> Cc: rest-discuss@yahoogroups.com
                        >> Sent: Friday, May 04, 2012 2:28 PM
                        >> Subject: RE: [rest-discuss] Re: Rel attributes?
                        >>
                        >>
                        >>
                        >> Hi Paul,
                        >>
                        >> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                        >> href.
                        >>
                        >> Also in atompub, app:collection/accept/text() tells you you can POST the
                        >> app:collection/@href whatever MIME types are
                        >> listed in the app:accept text().
                        >>
                        >> Going by that as an exemplar, it seems to me that it is the hypermedia
                        >> format which is defining what can and can't be
                        >> done against the URL.  Maybe that is out of band knowledge, but then again,
                        >> knowing what @method="POST" means
                        >> could be considered out of band too.   It has to be written down somewhere
                        >> and agreed to.  So the sharing of the semantics
                        >> widely is key to interoperability.  Hence a public link relations registry.
                        >> It is the shared semantics that allows us to
                        >> program user agents to do predictable things when they come across a
                        >> particular hypermedia construct.
                        >>
                        >> Maybe it is important that when a GET is done on a resource, that the
                        >> response metadata also declare the available methods.
                        >> Message metadata is authoritative.
                        >>
                        >> But you should not have to do that GET, because it is a waste of bandwidth,
                        >> and the representation format has already
                        >> defined (in the registry) and declared (in the instance in which you find
                        >> the href) the (possibly implicit) method availabilities.
                        >>
                        >>> 3. It is important to understand that the rel is the relation the resource
                        >>> identified by the link's URI, has with the actual resource/uri/document.
                        >>> It is not good if you use rel to denote other information, like saying
                        >>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                        >>> to create something. That is not the intended use and it is a bad
                        >>> practice.
                        >>
                        >> It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                        >> lot like the atom:link@rel="edit", or html's @method="POST".
                        >>
                        >> Cheers,
                        >> Peter
                        >>
                        >>
                        >>
                        >>
                        >>
                        >> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                        >> Behalf Of paul_k_moore
                        >> Sent: May 3, 2012 11:00
                        >> To: rest-discuss@yahoogroups.com
                        >> Subject: [rest-discuss] Re: Rel attributes?
                        >>
                        >>
                        >>
                        >>
                        >>
                        >> William
                        >>
                        >> This is very useful - thank you.
                        >>
                        >> Just to confirm my (refined) understanding here, I consider the meaning of
                        >> 'rel' to be an orthogonal concern to the HTTP methods.
                        >>
                        >> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                        >> at the target URI) into the meaning of 'rel'. If we consider the following
                        >> two examples:
                        >>
                        >> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                        >> reasonably conveys to the user-agent that there is something 'order'-like at
                        >> the target URI. It is then up to the client (the client intent) to follow
                        >> this rel (using an implicit GET request) to retrieve the representation of
                        >> the 'order'-like thing (as rendered in a specific media-type).
                        >>
                        >> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                        >> (unreasonably) convey that the user agent can POST an item of the type
                        >> communicated by it's current context. This is the problem, I don't need to
                        >> 'say' to the user-agent that it can POST at a specific URI, because the
                        >> available HTTP methods tell me what I can do with the resource. What I need
                        >> to do is examine the permitted methods (either by inspection of the 'Allow'
                        >> header, or an OPTIONS request) AND not try to convey the permutations of
                        >> method in the 'rel'.
                        >>
                        >> Does that make sense?
                        >>
                        >> Thanks in advance
                        >>
                        >> Paul
                        >>
                        >> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                        >> <wmartinez@...> wrote:
                        >>>
                        >>> Hi nikonguy74!
                        >>> Just to complement what Jan is saying:
                        >>> 1. Links represent resources you can work with. The idea of links is that
                        >>> you can usually follow them (issuing a GET operation), but then there are
                        >>> lots of questions you may have about them: what do I do with the actual
                        >>> resource (say, web page) I'm in? What is this link referring to? What
                        >>> other operations apart from GET can I execute with it? Can I add query
                        >>> parameters to it? What media type will it return? What media type may it
                        >>> expect if I can issue a POST?, etc...
                        >>>
                        >>> 2. rel is an attribute to add more information about a link. I denotes a
                        >>> value, keyword, hint of what relation the link has with the current
                        >>> resource/IRI. Say you are in a book page, that is your current resources
                        >>> and it has a URI. A link with rel="next" will hint that following that
                        >>> link will get you to the next page of the book.
                        >>>
                        >>> 3. It is important to understand that the rel is the relation the resource
                        >>> identified by the link's URI, has with the actual resource/uri/document.
                        >>> It is not good if you use rel to denote other information, like saying
                        >>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                        >>> to create something. That is not the intended use and it is a bad
                        >>> practice.
                        >>>
                        >>> 4. You may need actual business intelligence in your client. If you are
                        >>> looking at a blog comment, a rel="parent" will tell you the links points
                        >>> to the actual blog post. Having that information, you can start asking
                        >>> that parent for information, or even send a comment to it using POST
                        >>> operation. That is natural simply because much of this interaction is
                        >>> already designed in the specs, and the agent may not need to be statically
                        >>> programmed, but it will need intelligence.
                        >>>
                        >>> 5. So, you have there standard metainformation (like how to handle media
                        >>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                        >>> Plus, you have business specific semantics (the actual value of the rel
                        >>> may mean something applicable only to, say, banking applications). With
                        >>> that info you can program intelligent clients.
                        >>>
                        >>> 6. Finally, some other "link" tags like anchor and image are special links
                        >>> that have a standard meaning and established processing. If you found an
                        >>> <img> tag you automatically know that link is referring to an image, and
                        >>> if you are in HTML page in a browser, the supposed processing it to fetch
                        >>> that image with a GET and display it based on context and additional
                        >>> attributes. All that is told by the tag name, and everybody in the world
                        >>> knows it. So, links are difficult to understand at first but once you have
                        >>> it clear they are simple to use. Only don't expect the link rel attribute
                        >>> will tell you everything.
                        >>>
                        >>> Cheers
                        >>>
                        >>> William Martinez.
                        >>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                        >>> wrote:
                        >>> >
                        >>> >
                        >>> > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                        >>> > >
                        >>> > > I know one of the first questions i had was on rel link. I understand
                        >>> > > the basic premise behind rel attributes(to provide a general
                        >>> > > documentation for how to interact with the link provider).
                        >>> >
                        >>> > The premise of the rel attribute on links is (in the case of the HTML or
                        >>> > Atom media types) to provide information about the meaning of the link
                        >>> > beyond 'this is a link'. If you register your rel name in the IANA
                        >>> > registry, you can use the short name you registered, e.g. 'next' or
                        >>> > 'up'. If you did not register your rel, you need to provide a URI.
                        >>> > Simply for the matter of making your rel unambiguous.
                        >>> >
                        >>> > If that URI points to a human readable page explaining the relation,
                        >>> > then that is even better.
                        >>> >
                        >>> > There is no magic (not even in REST :-) that removes the need to
                        >>> > implement in code (or configure) what the user agent should do when it
                        >>> > sees your link rel value.
                        >>> >
                        >>> > <link rel="http://foo/customerDetails" ... /> is conceptually the same
                        >>> > as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                        >>> > AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                        >>> > user agent needs to be programmed to do something with ... in order to
                        >>> > have it do something with it.
                        >>> >
                        >>> > IOW, your browser downloads that image because it is programmed to do
                        >>> > so. This same concept also applies to other hypermedia - your user agent
                        >>> > component will act on the hypermedia it comes across in the way it is
                        >>> > programmed (or configured) to do.
                        >>> >
                        >>> > No magic.
                        >>> >
                        >>> > The effect of the hypermedia constraint is actually more felt in the
                        >>> > obligations you have as a client side programmer (to react to the
                        >>> > hypermedia you actually come across instead of the one you presume to
                        >>> > come across) than it is felt in the aspect of loose coupling.
                        >>> >
                        >>> > REST mostly makes explicit that there isn't any control over the server
                        >>> > side in networked systems. REST encourages you to deal with that rather
                        >>> > than magically solves a problem that cannot be solved. And on top of
                        >>> > that, REST provides a number of mechanism that optimize for *dealing
                        >>> > with* the problem (e.g. content negotiation).
                        >>> >
                        >>> > HTH,
                        >>> >
                        >>> > Jan
                        >>> >
                        >>> > > The question is what would you see if you go to the rel link? Is it
                        >>> > > something a person is suppose to interact with (say to get
                        >>> > > documentation for new links added to a specific response) or something
                        >>> > > code can interact with to determine what it needs to do? Unfortunately
                        >>> > > in the book they don't give an example of what a "rel" page would look
                        >>> > > like. For example the link:
                        >>> > > <link rel="http://relations.restbucks.com/payment"
                        >>> > > href:="http://restbucks.com/payment/1234" />
                        >>> > >
                        >>> > > If you typed in "http://relations.restbucks.com/payment" into your web
                        >>> > > browser what would you see?
                        >>> > >
                        >>> > > thanks...
                        >>> > >
                        >>> > >
                        >>> >
                        >>>
                        >>
                        >>
                        >>
                        >>
                        >>
                        >>
                        >> ------------------------------------
                        >>
                        >> Yahoo! Groups Links
                        >>
                        >>
                        >>
                        >
                        >
                        > ------------------------------------
                        >
                        > Yahoo! Groups Links
                        >
                        >
                        >
                      • Jorn Wildt
                        In my opinion it is bad. The server should include http method and payload format (but you only asked to compare the two formats). The client should only know
                        Message 11 of 23 , May 5, 2012
                        • 0 Attachment
                          In my opinion it is bad. The server should include http method and payload format (but you only asked to compare the two formats). The client should only know the "action" name and the set of parameters to transfer - it is then left to the server to specify the rest in a form language defined by the media type of the current message.

                          /Jørn

                          --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                          >
                          > note that neither option contains: http method or encoding information.
                          >
                          > that is "out of band" knowledge in these designs.
                          >
                          > is that "good" or "bad" here?
                          >
                          > mca
                          > http://amundsen.com/blog/
                          > http://twitter.com@mamund
                          > http://mamund.com/foaf.rdf#me
                          >
                          >
                          >
                          > On Sat, May 5, 2012 at 6:26 AM, Rushforth, Peter
                          > <peter.rushforth@...> wrote:
                          > > Hi Mike,
                          > >
                          > > A couple of my replies through the yahoo web interface have gone awol.
                          > >
                          > > Thanks for this.
                          > >
                          > > Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
                          > > The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.
                          > >
                          > > Cheers,
                          > > Peter
                          > > ________________________________________
                          > > From: mca@... [mca@...] on behalf of mike amundsen [mamund@...]
                          > > Sent: May 5, 2012 1:04 AM
                          > > To: Jørn Wildt
                          > > Cc: paul_k_moore; Rushforth, Peter; rest-discuss@yahoogroups.com
                          > > Subject: Re: [rest-discuss] Re: Rel attributes?
                          > >
                          > > Jørn, Paul, Peter:
                          > >
                          > > here are two options for a hypermedia affordances in a media type
                          > > design that supports writing new and updating existing resources:
                          > >
                          > > <create href="..." >...</create>
                          > > <update href="...">...</update>
                          > > OR
                          > > <write href="..." action="create">...</write>
                          > > <write href="..." action="update">...</write>
                          > >
                          > > Which relies on more "out-of-band" knowledge?
                          > > Which is a "better" design and why?
                          > >
                          > > mca
                          > > http://amundsen.com/blog/
                          > > http://twitter.com@mamund
                          > > http://mamund.com/foaf.rdf#me
                          > >
                          > >
                          > >
                          > > On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                          > >>> > It is not good if you use rel to denote other information,
                          > >>> > like saying rel="CreateWithPost" to hint the agent to
                          > >>> > use the link's URI with a POST to create something.
                          > >>> > That is not the intended use and it is a bad practice.
                          > >>
                          > >>> It seems reasonable to me, I don't see why it is a bad practice.
                          > >>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                          > >>
                          > >> I would say that you can do rel="CreateWithPost" and declare that in the
                          > >> link-rel documentation. But you loose something by doing so: allowing the
                          > >> server to specify HTTP method and payload encoding at runtime (since that
                          > >> knowledge would have to be a hardcoded part of the link-rel knowledge).
                          > >>
                          > >> Had the link "Create" instead lead to a form of some kind then the form
                          > >> could specifiy HTTP method at runtime, thus letting the server evolve over
                          > >> time (changing HTTP method) without updating the clients (as they are
                          > >> expected to understand the full form language).
                          > >>
                          > >> I haved tried to illustrate this in
                          > >> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                          > >> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                          > >>
                          > >> /Jørn
                          > >>
                          > >> ----- Original Message -----
                          > >> From: Rushforth, Peter
                          > >> To: paul_k_moore
                          > >> Cc: rest-discuss@yahoogroups.com
                          > >> Sent: Friday, May 04, 2012 2:28 PM
                          > >> Subject: RE: [rest-discuss] Re: Rel attributes?
                          > >>
                          > >>
                          > >>
                          > >> Hi Paul,
                          > >>
                          > >> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                          > >> href.
                          > >>
                          > >> Also in atompub, app:collection/accept/text() tells you you can POST the
                          > >> app:collection/@href whatever MIME types are
                          > >> listed in the app:accept text().
                          > >>
                          > >> Going by that as an exemplar, it seems to me that it is the hypermedia
                          > >> format which is defining what can and can't be
                          > >> done against the URL.  Maybe that is out of band knowledge, but then again,
                          > >> knowing what @method="POST" means
                          > >> could be considered out of band too.   It has to be written down somewhere
                          > >> and agreed to.  So the sharing of the semantics
                          > >> widely is key to interoperability.  Hence a public link relations registry.
                          > >> It is the shared semantics that allows us to
                          > >> program user agents to do predictable things when they come across a
                          > >> particular hypermedia construct.
                          > >>
                          > >> Maybe it is important that when a GET is done on a resource, that the
                          > >> response metadata also declare the available methods.
                          > >> Message metadata is authoritative.
                          > >>
                          > >> But you should not have to do that GET, because it is a waste of bandwidth,
                          > >> and the representation format has already
                          > >> defined (in the registry) and declared (in the instance in which you find
                          > >> the href) the (possibly implicit) method availabilities.
                          > >>
                          > >>> 3. It is important to understand that the rel is the relation the resource
                          > >>> identified by the link's URI, has with the actual resource/uri/document.
                          > >>> It is not good if you use rel to denote other information, like saying
                          > >>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                          > >>> to create something. That is not the intended use and it is a bad
                          > >>> practice.
                          > >>
                          > >> It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                          > >> lot like the atom:link@rel="edit", or html's @method="POST".
                          > >>
                          > >> Cheers,
                          > >> Peter
                          > >>
                          > >>
                          > >>
                          > >>
                          > >>
                          > >> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                          > >> Behalf Of paul_k_moore
                          > >> Sent: May 3, 2012 11:00
                          > >> To: rest-discuss@yahoogroups.com
                          > >> Subject: [rest-discuss] Re: Rel attributes?
                          > >>
                          > >>
                          > >>
                          > >>
                          > >>
                          > >> William
                          > >>
                          > >> This is very useful - thank you.
                          > >>
                          > >> Just to confirm my (refined) understanding here, I consider the meaning of
                          > >> 'rel' to be an orthogonal concern to the HTTP methods.
                          > >>
                          > >> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                          > >> at the target URI) into the meaning of 'rel'. If we consider the following
                          > >> two examples:
                          > >>
                          > >> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                          > >> reasonably conveys to the user-agent that there is something 'order'-like at
                          > >> the target URI. It is then up to the client (the client intent) to follow
                          > >> this rel (using an implicit GET request) to retrieve the representation of
                          > >> the 'order'-like thing (as rendered in a specific media-type).
                          > >>
                          > >> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                          > >> (unreasonably) convey that the user agent can POST an item of the type
                          > >> communicated by it's current context. This is the problem, I don't need to
                          > >> 'say' to the user-agent that it can POST at a specific URI, because the
                          > >> available HTTP methods tell me what I can do with the resource. What I need
                          > >> to do is examine the permitted methods (either by inspection of the 'Allow'
                          > >> header, or an OPTIONS request) AND not try to convey the permutations of
                          > >> method in the 'rel'.
                          > >>
                          > >> Does that make sense?
                          > >>
                          > >> Thanks in advance
                          > >>
                          > >> Paul
                          > >>
                          > >> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                          > >> <wmartinez@> wrote:
                          > >>>
                          > >>> Hi nikonguy74!
                          > >>> Just to complement what Jan is saying:
                          > >>> 1. Links represent resources you can work with. The idea of links is that
                          > >>> you can usually follow them (issuing a GET operation), but then there are
                          > >>> lots of questions you may have about them: what do I do with the actual
                          > >>> resource (say, web page) I'm in? What is this link referring to? What
                          > >>> other operations apart from GET can I execute with it? Can I add query
                          > >>> parameters to it? What media type will it return? What media type may it
                          > >>> expect if I can issue a POST?, etc...
                          > >>>
                          > >>> 2. rel is an attribute to add more information about a link. I denotes a
                          > >>> value, keyword, hint of what relation the link has with the current
                          > >>> resource/IRI. Say you are in a book page, that is your current resources
                          > >>> and it has a URI. A link with rel="next" will hint that following that
                          > >>> link will get you to the next page of the book.
                          > >>>
                          > >>> 3. It is important to understand that the rel is the relation the resource
                          > >>> identified by the link's URI, has with the actual resource/uri/document.
                          > >>> It is not good if you use rel to denote other information, like saying
                          > >>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                          > >>> to create something. That is not the intended use and it is a bad
                          > >>> practice.
                          > >>>
                          > >>> 4. You may need actual business intelligence in your client. If you are
                          > >>> looking at a blog comment, a rel="parent" will tell you the links points
                          > >>> to the actual blog post. Having that information, you can start asking
                          > >>> that parent for information, or even send a comment to it using POST
                          > >>> operation. That is natural simply because much of this interaction is
                          > >>> already designed in the specs, and the agent may not need to be statically
                          > >>> programmed, but it will need intelligence.
                          > >>>
                          > >>> 5. So, you have there standard metainformation (like how to handle media
                          > >>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                          > >>> Plus, you have business specific semantics (the actual value of the rel
                          > >>> may mean something applicable only to, say, banking applications). With
                          > >>> that info you can program intelligent clients.
                          > >>>
                          > >>> 6. Finally, some other "link" tags like anchor and image are special links
                          > >>> that have a standard meaning and established processing. If you found an
                          > >>> <img> tag you automatically know that link is referring to an image, and
                          > >>> if you are in HTML page in a browser, the supposed processing it to fetch
                          > >>> that image with a GET and display it based on context and additional
                          > >>> attributes. All that is told by the tag name, and everybody in the world
                          > >>> knows it. So, links are difficult to understand at first but once you have
                          > >>> it clear they are simple to use. Only don't expect the link rel attribute
                          > >>> will tell you everything.
                          > >>>
                          > >>> Cheers
                          > >>>
                          > >>> William Martinez.
                          > >>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                          > >>> wrote:
                          > >>> >
                          > >>> >
                          > >>> > On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                          > >>> > >
                          > >>> > > I know one of the first questions i had was on rel link. I understand
                          > >>> > > the basic premise behind rel attributes(to provide a general
                          > >>> > > documentation for how to interact with the link provider).
                          > >>> >
                          > >>> > The premise of the rel attribute on links is (in the case of the HTML or
                          > >>> > Atom media types) to provide information about the meaning of the link
                          > >>> > beyond 'this is a link'. If you register your rel name in the IANA
                          > >>> > registry, you can use the short name you registered, e.g. 'next' or
                          > >>> > 'up'. If you did not register your rel, you need to provide a URI.
                          > >>> > Simply for the matter of making your rel unambiguous.
                          > >>> >
                          > >>> > If that URI points to a human readable page explaining the relation,
                          > >>> > then that is even better.
                          > >>> >
                          > >>> > There is no magic (not even in REST :-) that removes the need to
                          > >>> > implement in code (or configure) what the user agent should do when it
                          > >>> > sees your link rel value.
                          > >>> >
                          > >>> > <link rel="http://foo/customerDetails" ... /> is conceptually the same
                          > >>> > as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                          > >>> > AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                          > >>> > user agent needs to be programmed to do something with ... in order to
                          > >>> > have it do something with it.
                          > >>> >
                          > >>> > IOW, your browser downloads that image because it is programmed to do
                          > >>> > so. This same concept also applies to other hypermedia - your user agent
                          > >>> > component will act on the hypermedia it comes across in the way it is
                          > >>> > programmed (or configured) to do.
                          > >>> >
                          > >>> > No magic.
                          > >>> >
                          > >>> > The effect of the hypermedia constraint is actually more felt in the
                          > >>> > obligations you have as a client side programmer (to react to the
                          > >>> > hypermedia you actually come across instead of the one you presume to
                          > >>> > come across) than it is felt in the aspect of loose coupling.
                          > >>> >
                          > >>> > REST mostly makes explicit that there isn't any control over the server
                          > >>> > side in networked systems. REST encourages you to deal with that rather
                          > >>> > than magically solves a problem that cannot be solved. And on top of
                          > >>> > that, REST provides a number of mechanism that optimize for *dealing
                          > >>> > with* the problem (e.g. content negotiation).
                          > >>> >
                          > >>> > HTH,
                          > >>> >
                          > >>> > Jan
                          > >>> >
                          > >>> > > The question is what would you see if you go to the rel link? Is it
                          > >>> > > something a person is suppose to interact with (say to get
                          > >>> > > documentation for new links added to a specific response) or something
                          > >>> > > code can interact with to determine what it needs to do? Unfortunately
                          > >>> > > in the book they don't give an example of what a "rel" page would look
                          > >>> > > like. For example the link:
                          > >>> > > <link rel="http://relations.restbucks.com/payment"
                          > >>> > > href:="http://restbucks.com/payment/1234" />
                          > >>> > >
                          > >>> > > If you typed in "http://relations.restbucks.com/payment" into your web
                          > >>> > > browser what would you see?
                          > >>> > >
                          > >>> > > thanks...
                          > >>> > >
                          > >>> > >
                          > >>> >
                          > >>>
                          > >>
                          > >>
                          > >>
                          > >>
                          > >>
                          > >>
                          > >> ------------------------------------
                          > >>
                          > >> Yahoo! Groups Links
                          > >>
                          > >>
                          > >>
                          > >
                          > >
                          > > ------------------------------------
                          > >
                          > > Yahoo! Groups Links
                          > >
                          > >
                          > >
                          >
                        • Paul Moore
                          Mike, Irrespective of the (en)coding variants below, how are create and update defined in your media type for this context? Paul
                          Message 12 of 23 , May 5, 2012
                          • 0 Attachment
                            Mike,

                            Irrespective of the (en)coding variants below, how are 'create' and 'update' defined in your media type for this context?

                            Paul

                            On 5 May 2012, at 06:04, mike amundsen wrote:

                            > Jørn, Paul, Peter:
                            >
                            > here are two options for a hypermedia affordances in a media type
                            > design that supports writing new and updating existing resources:
                            >
                            > <create href="..." >...</create>
                            > <update href="...">...</update>
                            > OR
                            > <write href="..." action="create">...</write>
                            > <write href="..." action="update">...</write>
                            >
                            > Which relies on more "out-of-band" knowledge?
                            > Which is a "better" design and why?
                            >
                            > mca
                            > http://amundsen.com/blog/
                            > http://twitter.com@mamund
                            > http://mamund.com/foaf.rdf#me
                            >
                            >
                            >
                            > On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                            >>>> It is not good if you use rel to denote other information,
                            >>>> like saying rel="CreateWithPost" to hint the agent to
                            >>>> use the link's URI with a POST to create something.
                            >>>> That is not the intended use and it is a bad practice.
                            >>
                            >>> It seems reasonable to me, I don't see why it is a bad practice.
                            >>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                            >>
                            >> I would say that you can do rel="CreateWithPost" and declare that in the
                            >> link-rel documentation. But you loose something by doing so: allowing the
                            >> server to specify HTTP method and payload encoding at runtime (since that
                            >> knowledge would have to be a hardcoded part of the link-rel knowledge).
                            >>
                            >> Had the link "Create" instead lead to a form of some kind then the form
                            >> could specifiy HTTP method at runtime, thus letting the server evolve over
                            >> time (changing HTTP method) without updating the clients (as they are
                            >> expected to understand the full form language).
                            >>
                            >> I haved tried to illustrate this in
                            >> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                            >> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                            >>
                            >> /Jørn
                            >>
                            >> ----- Original Message -----
                            >> From: Rushforth, Peter
                            >> To: paul_k_moore
                            >> Cc: rest-discuss@yahoogroups.com
                            >> Sent: Friday, May 04, 2012 2:28 PM
                            >> Subject: RE: [rest-discuss] Re: Rel attributes?
                            >>
                            >>
                            >>
                            >> Hi Paul,
                            >>
                            >> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                            >> href.
                            >>
                            >> Also in atompub, app:collection/accept/text() tells you you can POST the
                            >> app:collection/@href whatever MIME types are
                            >> listed in the app:accept text().
                            >>
                            >> Going by that as an exemplar, it seems to me that it is the hypermedia
                            >> format which is defining what can and can't be
                            >> done against the URL. Maybe that is out of band knowledge, but then again,
                            >> knowing what @method="POST" means
                            >> could be considered out of band too. It has to be written down somewhere
                            >> and agreed to. So the sharing of the semantics
                            >> widely is key to interoperability. Hence a public link relations registry.
                            >> It is the shared semantics that allows us to
                            >> program user agents to do predictable things when they come across a
                            >> particular hypermedia construct.
                            >>
                            >> Maybe it is important that when a GET is done on a resource, that the
                            >> response metadata also declare the available methods.
                            >> Message metadata is authoritative.
                            >>
                            >> But you should not have to do that GET, because it is a waste of bandwidth,
                            >> and the representation format has already
                            >> defined (in the registry) and declared (in the instance in which you find
                            >> the href) the (possibly implicit) method availabilities.
                            >>
                            >>> 3. It is important to understand that the rel is the relation the resource
                            >>> identified by the link's URI, has with the actual resource/uri/document.
                            >>> It is not good if you use rel to denote other information, like saying
                            >>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                            >>> to create something. That is not the intended use and it is a bad
                            >>> practice.
                            >>
                            >> It seems reasonable to me, I don't see why it is a bad practice. It looks a
                            >> lot like the atom:link@rel="edit", or html's @method="POST".
                            >>
                            >> Cheers,
                            >> Peter
                            >>
                            >>
                            >>
                            >>
                            >>
                            >> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                            >> Behalf Of paul_k_moore
                            >> Sent: May 3, 2012 11:00
                            >> To: rest-discuss@yahoogroups.com
                            >> Subject: [rest-discuss] Re: Rel attributes?
                            >>
                            >>
                            >>
                            >>
                            >>
                            >> William
                            >>
                            >> This is very useful - thank you.
                            >>
                            >> Just to confirm my (refined) understanding here, I consider the meaning of
                            >> 'rel' to be an orthogonal concern to the HTTP methods.
                            >>
                            >> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                            >> at the target URI) into the meaning of 'rel'. If we consider the following
                            >> two examples:
                            >>
                            >> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                            >> reasonably conveys to the user-agent that there is something 'order'-like at
                            >> the target URI. It is then up to the client (the client intent) to follow
                            >> this rel (using an implicit GET request) to retrieve the representation of
                            >> the 'order'-like thing (as rendered in a specific media-type).
                            >>
                            >> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                            >> (unreasonably) convey that the user agent can POST an item of the type
                            >> communicated by it's current context. This is the problem, I don't need to
                            >> 'say' to the user-agent that it can POST at a specific URI, because the
                            >> available HTTP methods tell me what I can do with the resource. What I need
                            >> to do is examine the permitted methods (either by inspection of the 'Allow'
                            >> header, or an OPTIONS request) AND not try to convey the permutations of
                            >> method in the 'rel'.
                            >>
                            >> Does that make sense?
                            >>
                            >> Thanks in advance
                            >>
                            >> Paul
                            >>
                            >> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                            >> <wmartinez@...> wrote:
                            >>>
                            >>> Hi nikonguy74!
                            >>> Just to complement what Jan is saying:
                            >>> 1. Links represent resources you can work with. The idea of links is that
                            >>> you can usually follow them (issuing a GET operation), but then there are
                            >>> lots of questions you may have about them: what do I do with the actual
                            >>> resource (say, web page) I'm in? What is this link referring to? What
                            >>> other operations apart from GET can I execute with it? Can I add query
                            >>> parameters to it? What media type will it return? What media type may it
                            >>> expect if I can issue a POST?, etc...
                            >>>
                            >>> 2. rel is an attribute to add more information about a link. I denotes a
                            >>> value, keyword, hint of what relation the link has with the current
                            >>> resource/IRI. Say you are in a book page, that is your current resources
                            >>> and it has a URI. A link with rel="next" will hint that following that
                            >>> link will get you to the next page of the book.
                            >>>
                            >>> 3. It is important to understand that the rel is the relation the resource
                            >>> identified by the link's URI, has with the actual resource/uri/document.
                            >>> It is not good if you use rel to denote other information, like saying
                            >>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                            >>> to create something. That is not the intended use and it is a bad
                            >>> practice.
                            >>>
                            >>> 4. You may need actual business intelligence in your client. If you are
                            >>> looking at a blog comment, a rel="parent" will tell you the links points
                            >>> to the actual blog post. Having that information, you can start asking
                            >>> that parent for information, or even send a comment to it using POST
                            >>> operation. That is natural simply because much of this interaction is
                            >>> already designed in the specs, and the agent may not need to be statically
                            >>> programmed, but it will need intelligence.
                            >>>
                            >>> 5. So, you have there standard metainformation (like how to handle media
                            >>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                            >>> Plus, you have business specific semantics (the actual value of the rel
                            >>> may mean something applicable only to, say, banking applications). With
                            >>> that info you can program intelligent clients.
                            >>>
                            >>> 6. Finally, some other "link" tags like anchor and image are special links
                            >>> that have a standard meaning and established processing. If you found an
                            >>> <img> tag you automatically know that link is referring to an image, and
                            >>> if you are in HTML page in a browser, the supposed processing it to fetch
                            >>> that image with a GET and display it based on context and additional
                            >>> attributes. All that is told by the tag name, and everybody in the world
                            >>> knows it. So, links are difficult to understand at first but once you have
                            >>> it clear they are simple to use. Only don't expect the link rel attribute
                            >>> will tell you everything.
                            >>>
                            >>> Cheers
                            >>>
                            >>> William Martinez.
                            >>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                            >>> wrote:
                            >>>>
                            >>>>
                            >>>> On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                            >>>>>
                            >>>>> I know one of the first questions i had was on rel link. I understand
                            >>>>> the basic premise behind rel attributes(to provide a general
                            >>>>> documentation for how to interact with the link provider).
                            >>>>
                            >>>> The premise of the rel attribute on links is (in the case of the HTML or
                            >>>> Atom media types) to provide information about the meaning of the link
                            >>>> beyond 'this is a link'. If you register your rel name in the IANA
                            >>>> registry, you can use the short name you registered, e.g. 'next' or
                            >>>> 'up'. If you did not register your rel, you need to provide a URI.
                            >>>> Simply for the matter of making your rel unambiguous.
                            >>>>
                            >>>> If that URI points to a human readable page explaining the relation,
                            >>>> then that is even better.
                            >>>>
                            >>>> There is no magic (not even in REST :-) that removes the need to
                            >>>> implement in code (or configure) what the user agent should do when it
                            >>>> sees your link rel value.
                            >>>>
                            >>>> <link rel="http://foo/customerDetails" ... /> is conceptually the same
                            >>>> as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                            >>>> AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                            >>>> user agent needs to be programmed to do something with ... in order to
                            >>>> have it do something with it.
                            >>>>
                            >>>> IOW, your browser downloads that image because it is programmed to do
                            >>>> so. This same concept also applies to other hypermedia - your user agent
                            >>>> component will act on the hypermedia it comes across in the way it is
                            >>>> programmed (or configured) to do.
                            >>>>
                            >>>> No magic.
                            >>>>
                            >>>> The effect of the hypermedia constraint is actually more felt in the
                            >>>> obligations you have as a client side programmer (to react to the
                            >>>> hypermedia you actually come across instead of the one you presume to
                            >>>> come across) than it is felt in the aspect of loose coupling.
                            >>>>
                            >>>> REST mostly makes explicit that there isn't any control over the server
                            >>>> side in networked systems. REST encourages you to deal with that rather
                            >>>> than magically solves a problem that cannot be solved. And on top of
                            >>>> that, REST provides a number of mechanism that optimize for *dealing
                            >>>> with* the problem (e.g. content negotiation).
                            >>>>
                            >>>> HTH,
                            >>>>
                            >>>> Jan
                            >>>>
                            >>>>> The question is what would you see if you go to the rel link? Is it
                            >>>>> something a person is suppose to interact with (say to get
                            >>>>> documentation for new links added to a specific response) or something
                            >>>>> code can interact with to determine what it needs to do? Unfortunately
                            >>>>> in the book they don't give an example of what a "rel" page would look
                            >>>>> like. For example the link:
                            >>>>> <link rel="http://relations.restbucks.com/payment"
                            >>>>> href:="http://restbucks.com/payment/1234" />
                            >>>>>
                            >>>>> If you typed in "http://relations.restbucks.com/payment" into your web
                            >>>>> browser what would you see?
                            >>>>>
                            >>>>> thanks...
                            >>>>>
                            >>>>>
                            >>>>
                            >>>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >>
                            >> ------------------------------------
                            >>
                            >> Yahoo! Groups Links
                            >>
                            >>
                            >>
                          • mike amundsen
                            Jørn: do you think the following design elements are also bad ? HTML.IMG HTML.A HTML.LINK HTML.IFRAME HTML.SCRIPT mca http://amundsen.com/blog/
                            Message 13 of 23 , May 5, 2012
                            • 0 Attachment
                              Jørn:

                              do you think the following design elements are also "bad"?

                              HTML.IMG
                              HTML.A
                              HTML.LINK
                              HTML.IFRAME
                              HTML.SCRIPT

                              mca
                              http://amundsen.com/blog/
                              http://twitter.com@mamund
                              http://mamund.com/foaf.rdf#me



                              On Sat, May 5, 2012 at 8:07 AM, Jørn wildt <jornwildt@...> wrote:
                              > In my opinion it is bad. The server should include http method and payload format (but you only asked to compare the two formats). The client should only know the "action" name and the set of parameters to transfer - it is then left to the server to specify the rest in a form language defined by the media type of the current message.
                              >
                              > /Jørn
                              >
                              >
                              > Sendt fra min iPad
                              >
                              > Den 05/05/2012 kl. 12.39 skrev mike amundsen <mamund@...>:
                              >
                              >> note that neither option contains: http method or encoding information.
                              >>
                              >> that is "out of band" knowledge in these designs.
                              >>
                              >> is that "good" or "bad" here?
                              >>
                              >> mca
                              >> http://amundsen.com/blog/
                              >> http://twitter.com@mamund
                              >> http://mamund.com/foaf.rdf#me
                              >>
                              >>
                              >>
                              >> On Sat, May 5, 2012 at 6:26 AM, Rushforth, Peter
                              >> <peter.rushforth@...> wrote:
                              >>> Hi Mike,
                              >>>
                              >>> A couple of my replies through the yahoo web interface have gone awol.
                              >>>
                              >>> Thanks for this.
                              >>>
                              >>> Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
                              >>> The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.
                              >>>
                              >>> Cheers,
                              >>> Peter
                              >>> ________________________________________
                              >>> From: mca@... [mca@...] on behalf of mike amundsen [mamund@...]
                              >>> Sent: May 5, 2012 1:04 AM
                              >>> To: Jørn Wildt
                              >>> Cc: paul_k_moore; Rushforth, Peter; rest-discuss@yahoogroups.com
                              >>> Subject: Re: [rest-discuss] Re: Rel attributes?
                              >>>
                              >>> Jørn, Paul, Peter:
                              >>>
                              >>> here are two options for a hypermedia affordances in a media type
                              >>> design that supports writing new and updating existing resources:
                              >>>
                              >>> <create href="..." >...</create>
                              >>> <update href="...">...</update>
                              >>> OR
                              >>> <write href="..." action="create">...</write>
                              >>> <write href="..." action="update">...</write>
                              >>>
                              >>> Which relies on more "out-of-band" knowledge?
                              >>> Which is a "better" design and why?
                              >>>
                              >>> mca
                              >>> http://amundsen.com/blog/
                              >>> http://twitter.com@mamund
                              >>> http://mamund.com/foaf.rdf#me
                              >>>
                              >>>
                              >>>
                              >>> On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                              >>>>>> It is not good if you use rel to denote other information,
                              >>>>>> like saying rel="CreateWithPost" to hint the agent to
                              >>>>>> use the link's URI with a POST to create something.
                              >>>>>> That is not the intended use and it is a bad practice.
                              >>>>
                              >>>>> It seems reasonable to me, I don't see why it is a bad practice.
                              >>>>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                              >>>>
                              >>>> I would say that you can do rel="CreateWithPost" and declare that in the
                              >>>> link-rel documentation. But you loose something by doing so: allowing the
                              >>>> server to specify HTTP method and payload encoding at runtime (since that
                              >>>> knowledge would have to be a hardcoded part of the link-rel knowledge).
                              >>>>
                              >>>> Had the link "Create" instead lead to a form of some kind then the form
                              >>>> could specifiy HTTP method at runtime, thus letting the server evolve over
                              >>>> time (changing HTTP method) without updating the clients (as they are
                              >>>> expected to understand the full form language).
                              >>>>
                              >>>> I haved tried to illustrate this in
                              >>>> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                              >>>> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                              >>>>
                              >>>> /Jørn
                              >>>>
                              >>>> ----- Original Message -----
                              >>>> From: Rushforth, Peter
                              >>>> To: paul_k_moore
                              >>>> Cc: rest-discuss@yahoogroups.com
                              >>>> Sent: Friday, May 04, 2012 2:28 PM
                              >>>> Subject: RE: [rest-discuss] Re: Rel attributes?
                              >>>>
                              >>>>
                              >>>>
                              >>>> Hi Paul,
                              >>>>
                              >>>> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                              >>>> href.
                              >>>>
                              >>>> Also in atompub, app:collection/accept/text() tells you you can POST the
                              >>>> app:collection/@href whatever MIME types are
                              >>>> listed in the app:accept text().
                              >>>>
                              >>>> Going by that as an exemplar, it seems to me that it is the hypermedia
                              >>>> format which is defining what can and can't be
                              >>>> done against the URL.  Maybe that is out of band knowledge, but then again,
                              >>>> knowing what @method="POST" means
                              >>>> could be considered out of band too.   It has to be written down somewhere
                              >>>> and agreed to.  So the sharing of the semantics
                              >>>> widely is key to interoperability.  Hence a public link relations registry.
                              >>>> It is the shared semantics that allows us to
                              >>>> program user agents to do predictable things when they come across a
                              >>>> particular hypermedia construct.
                              >>>>
                              >>>> Maybe it is important that when a GET is done on a resource, that the
                              >>>> response metadata also declare the available methods.
                              >>>> Message metadata is authoritative.
                              >>>>
                              >>>> But you should not have to do that GET, because it is a waste of bandwidth,
                              >>>> and the representation format has already
                              >>>> defined (in the registry) and declared (in the instance in which you find
                              >>>> the href) the (possibly implicit) method availabilities.
                              >>>>
                              >>>>> 3. It is important to understand that the rel is the relation the resource
                              >>>>> identified by the link's URI, has with the actual resource/uri/document.
                              >>>>> It is not good if you use rel to denote other information, like saying
                              >>>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                              >>>>> to create something. That is not the intended use and it is a bad
                              >>>>> practice.
                              >>>>
                              >>>> It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                              >>>> lot like the atom:link@rel="edit", or html's @method="POST".
                              >>>>
                              >>>> Cheers,
                              >>>> Peter
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                              >>>> Behalf Of paul_k_moore
                              >>>> Sent: May 3, 2012 11:00
                              >>>> To: rest-discuss@yahoogroups.com
                              >>>> Subject: [rest-discuss] Re: Rel attributes?
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>> William
                              >>>>
                              >>>> This is very useful - thank you.
                              >>>>
                              >>>> Just to confirm my (refined) understanding here, I consider the meaning of
                              >>>> 'rel' to be an orthogonal concern to the HTTP methods.
                              >>>>
                              >>>> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                              >>>> at the target URI) into the meaning of 'rel'. If we consider the following
                              >>>> two examples:
                              >>>>
                              >>>> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                              >>>> reasonably conveys to the user-agent that there is something 'order'-like at
                              >>>> the target URI. It is then up to the client (the client intent) to follow
                              >>>> this rel (using an implicit GET request) to retrieve the representation of
                              >>>> the 'order'-like thing (as rendered in a specific media-type).
                              >>>>
                              >>>> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                              >>>> (unreasonably) convey that the user agent can POST an item of the type
                              >>>> communicated by it's current context. This is the problem, I don't need to
                              >>>> 'say' to the user-agent that it can POST at a specific URI, because the
                              >>>> available HTTP methods tell me what I can do with the resource. What I need
                              >>>> to do is examine the permitted methods (either by inspection of the 'Allow'
                              >>>> header, or an OPTIONS request) AND not try to convey the permutations of
                              >>>> method in the 'rel'.
                              >>>>
                              >>>> Does that make sense?
                              >>>>
                              >>>> Thanks in advance
                              >>>>
                              >>>> Paul
                              >>>>
                              >>>> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                              >>>> <wmartinez@...> wrote:
                              >>>>>
                              >>>>> Hi nikonguy74!
                              >>>>> Just to complement what Jan is saying:
                              >>>>> 1. Links represent resources you can work with. The idea of links is that
                              >>>>> you can usually follow them (issuing a GET operation), but then there are
                              >>>>> lots of questions you may have about them: what do I do with the actual
                              >>>>> resource (say, web page) I'm in? What is this link referring to? What
                              >>>>> other operations apart from GET can I execute with it? Can I add query
                              >>>>> parameters to it? What media type will it return? What media type may it
                              >>>>> expect if I can issue a POST?, etc...
                              >>>>>
                              >>>>> 2. rel is an attribute to add more information about a link. I denotes a
                              >>>>> value, keyword, hint of what relation the link has with the current
                              >>>>> resource/IRI. Say you are in a book page, that is your current resources
                              >>>>> and it has a URI. A link with rel="next" will hint that following that
                              >>>>> link will get you to the next page of the book.
                              >>>>>
                              >>>>> 3. It is important to understand that the rel is the relation the resource
                              >>>>> identified by the link's URI, has with the actual resource/uri/document.
                              >>>>> It is not good if you use rel to denote other information, like saying
                              >>>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                              >>>>> to create something. That is not the intended use and it is a bad
                              >>>>> practice.
                              >>>>>
                              >>>>> 4. You may need actual business intelligence in your client. If you are
                              >>>>> looking at a blog comment, a rel="parent" will tell you the links points
                              >>>>> to the actual blog post. Having that information, you can start asking
                              >>>>> that parent for information, or even send a comment to it using POST
                              >>>>> operation. That is natural simply because much of this interaction is
                              >>>>> already designed in the specs, and the agent may not need to be statically
                              >>>>> programmed, but it will need intelligence.
                              >>>>>
                              >>>>> 5. So, you have there standard metainformation (like how to handle media
                              >>>>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                              >>>>> Plus, you have business specific semantics (the actual value of the rel
                              >>>>> may mean something applicable only to, say, banking applications). With
                              >>>>> that info you can program intelligent clients.
                              >>>>>
                              >>>>> 6. Finally, some other "link" tags like anchor and image are special links
                              >>>>> that have a standard meaning and established processing. If you found an
                              >>>>> <img> tag you automatically know that link is referring to an image, and
                              >>>>> if you are in HTML page in a browser, the supposed processing it to fetch
                              >>>>> that image with a GET and display it based on context and additional
                              >>>>> attributes. All that is told by the tag name, and everybody in the world
                              >>>>> knows it. So, links are difficult to understand at first but once you have
                              >>>>> it clear they are simple to use. Only don't expect the link rel attribute
                              >>>>> will tell you everything.
                              >>>>>
                              >>>>> Cheers
                              >>>>>
                              >>>>> William Martinez.
                              >>>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                              >>>>> wrote:
                              >>>>>>
                              >>>>>>
                              >>>>>> On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                              >>>>>>>
                              >>>>>>> I know one of the first questions i had was on rel link. I understand
                              >>>>>>> the basic premise behind rel attributes(to provide a general
                              >>>>>>> documentation for how to interact with the link provider).
                              >>>>>>
                              >>>>>> The premise of the rel attribute on links is (in the case of the HTML or
                              >>>>>> Atom media types) to provide information about the meaning of the link
                              >>>>>> beyond 'this is a link'. If you register your rel name in the IANA
                              >>>>>> registry, you can use the short name you registered, e.g. 'next' or
                              >>>>>> 'up'. If you did not register your rel, you need to provide a URI.
                              >>>>>> Simply for the matter of making your rel unambiguous.
                              >>>>>>
                              >>>>>> If that URI points to a human readable page explaining the relation,
                              >>>>>> then that is even better.
                              >>>>>>
                              >>>>>> There is no magic (not even in REST :-) that removes the need to
                              >>>>>> implement in code (or configure) what the user agent should do when it
                              >>>>>> sees your link rel value.
                              >>>>>>
                              >>>>>> <link rel="http://foo/customerDetails" ... /> is conceptually the same
                              >>>>>> as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                              >>>>>> AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                              >>>>>> user agent needs to be programmed to do something with ... in order to
                              >>>>>> have it do something with it.
                              >>>>>>
                              >>>>>> IOW, your browser downloads that image because it is programmed to do
                              >>>>>> so. This same concept also applies to other hypermedia - your user agent
                              >>>>>> component will act on the hypermedia it comes across in the way it is
                              >>>>>> programmed (or configured) to do.
                              >>>>>>
                              >>>>>> No magic.
                              >>>>>>
                              >>>>>> The effect of the hypermedia constraint is actually more felt in the
                              >>>>>> obligations you have as a client side programmer (to react to the
                              >>>>>> hypermedia you actually come across instead of the one you presume to
                              >>>>>> come across) than it is felt in the aspect of loose coupling.
                              >>>>>>
                              >>>>>> REST mostly makes explicit that there isn't any control over the server
                              >>>>>> side in networked systems. REST encourages you to deal with that rather
                              >>>>>> than magically solves a problem that cannot be solved. And on top of
                              >>>>>> that, REST provides a number of mechanism that optimize for *dealing
                              >>>>>> with* the problem (e.g. content negotiation).
                              >>>>>>
                              >>>>>> HTH,
                              >>>>>>
                              >>>>>> Jan
                              >>>>>>
                              >>>>>>> The question is what would you see if you go to the rel link? Is it
                              >>>>>>> something a person is suppose to interact with (say to get
                              >>>>>>> documentation for new links added to a specific response) or something
                              >>>>>>> code can interact with to determine what it needs to do? Unfortunately
                              >>>>>>> in the book they don't give an example of what a "rel" page would look
                              >>>>>>> like. For example the link:
                              >>>>>>> <link rel="http://relations.restbucks.com/payment"
                              >>>>>>> href:="http://restbucks.com/payment/1234" />
                              >>>>>>>
                              >>>>>>> If you typed in "http://relations.restbucks.com/payment" into your web
                              >>>>>>> browser what would you see?
                              >>>>>>>
                              >>>>>>> thanks...
                              >>>>>>>
                              >>>>>>>
                              >>>>>>
                              >>>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>>
                              >>>> ------------------------------------
                              >>>>
                              >>>> Yahoo! Groups Links
                              >>>>
                              >>>>
                              >>>>
                              >>>
                              >>>
                              >>> ------------------------------------
                              >>>
                              >>> Yahoo! Groups Links
                              >>>
                              >>>
                              >>>
                            • mike amundsen
                              ... If i understand your question, the actual mapping of the protocol details to the message design differs depending on the protocol used. for an example of a
                              Message 14 of 23 , May 5, 2012
                              • 0 Attachment
                                > Irrespective of the (en)coding variants below, how are 'create' and 'update' defined in your media type for this context?
                                If i understand your question, the actual mapping of the protocol
                                details to the message design differs depending on the protocol used.

                                for an example of a very similar design (list, item, query), check out
                                this blog post that shows both HTTP and FTP "bindings" for the message
                                design:
                                http://www.amundsen.com/blog/archives/1041

                                mca
                                http://amundsen.com/blog/
                                http://twitter.com@mamund
                                http://mamund.com/foaf.rdf#me



                                On Sat, May 5, 2012 at 8:58 AM, Paul Moore <paul.k.moore@...> wrote:
                                > Mike,
                                >
                                > Irrespective of the (en)coding variants below, how are 'create' and 'update' defined in your media type for this context?
                                >
                                > Paul
                                >
                                > On 5 May 2012, at 06:04, mike amundsen wrote:
                                >
                                >> Jørn, Paul, Peter:
                                >>
                                >> here are two options for a hypermedia affordances in a media type
                                >> design that supports writing new and updating existing resources:
                                >>
                                >> <create href="..." >...</create>
                                >> <update href="...">...</update>
                                >> OR
                                >> <write href="..." action="create">...</write>
                                >> <write href="..." action="update">...</write>
                                >>
                                >> Which relies on more "out-of-band" knowledge?
                                >> Which is a "better" design and why?
                                >>
                                >> mca
                                >> http://amundsen.com/blog/
                                >> http://twitter.com@mamund
                                >> http://mamund.com/foaf.rdf#me
                                >>
                                >>
                                >>
                                >> On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                                >>>>> It is not good if you use rel to denote other information,
                                >>>>> like saying rel="CreateWithPost" to hint the agent to
                                >>>>> use the link's URI with a POST to create something.
                                >>>>> That is not the intended use and it is a bad practice.
                                >>>
                                >>>> It seems reasonable to me, I don't see why it is a bad practice.
                                >>>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                                >>>
                                >>> I would say that you can do rel="CreateWithPost" and declare that in the
                                >>> link-rel documentation. But you loose something by doing so: allowing the
                                >>> server to specify HTTP method and payload encoding at runtime (since that
                                >>> knowledge would have to be a hardcoded part of the link-rel knowledge).
                                >>>
                                >>> Had the link "Create" instead lead to a form of some kind then the form
                                >>> could specifiy HTTP method at runtime, thus letting the server evolve over
                                >>> time (changing HTTP method) without updating the clients (as they are
                                >>> expected to understand the full form language).
                                >>>
                                >>> I haved tried to illustrate this in
                                >>> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                                >>> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                                >>>
                                >>> /Jørn
                                >>>
                                >>> ----- Original Message -----
                                >>> From: Rushforth, Peter
                                >>> To: paul_k_moore
                                >>> Cc: rest-discuss@yahoogroups.com
                                >>> Sent: Friday, May 04, 2012 2:28 PM
                                >>> Subject: RE: [rest-discuss] Re: Rel attributes?
                                >>>
                                >>>
                                >>>
                                >>> Hi Paul,
                                >>>
                                >>> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                                >>> href.
                                >>>
                                >>> Also in atompub, app:collection/accept/text() tells you you can POST the
                                >>> app:collection/@href whatever MIME types are
                                >>> listed in the app:accept text().
                                >>>
                                >>> Going by that as an exemplar, it seems to me that it is the hypermedia
                                >>> format which is defining what can and can't be
                                >>> done against the URL.  Maybe that is out of band knowledge, but then again,
                                >>> knowing what @method="POST" means
                                >>> could be considered out of band too.   It has to be written down somewhere
                                >>> and agreed to.  So the sharing of the semantics
                                >>> widely is key to interoperability.  Hence a public link relations registry.
                                >>> It is the shared semantics that allows us to
                                >>> program user agents to do predictable things when they come across a
                                >>> particular hypermedia construct.
                                >>>
                                >>> Maybe it is important that when a GET is done on a resource, that the
                                >>> response metadata also declare the available methods.
                                >>> Message metadata is authoritative.
                                >>>
                                >>> But you should not have to do that GET, because it is a waste of bandwidth,
                                >>> and the representation format has already
                                >>> defined (in the registry) and declared (in the instance in which you find
                                >>> the href) the (possibly implicit) method availabilities.
                                >>>
                                >>>> 3. It is important to understand that the rel is the relation the resource
                                >>>> identified by the link's URI, has with the actual resource/uri/document.
                                >>>> It is not good if you use rel to denote other information, like saying
                                >>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                                >>>> to create something. That is not the intended use and it is a bad
                                >>>> practice.
                                >>>
                                >>> It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                                >>> lot like the atom:link@rel="edit", or html's @method="POST".
                                >>>
                                >>> Cheers,
                                >>> Peter
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                                >>> Behalf Of paul_k_moore
                                >>> Sent: May 3, 2012 11:00
                                >>> To: rest-discuss@yahoogroups.com
                                >>> Subject: [rest-discuss] Re: Rel attributes?
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>> William
                                >>>
                                >>> This is very useful - thank you.
                                >>>
                                >>> Just to confirm my (refined) understanding here, I consider the meaning of
                                >>> 'rel' to be an orthogonal concern to the HTTP methods.
                                >>>
                                >>> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                                >>> at the target URI) into the meaning of 'rel'. If we consider the following
                                >>> two examples:
                                >>>
                                >>> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                                >>> reasonably conveys to the user-agent that there is something 'order'-like at
                                >>> the target URI. It is then up to the client (the client intent) to follow
                                >>> this rel (using an implicit GET request) to retrieve the representation of
                                >>> the 'order'-like thing (as rendered in a specific media-type).
                                >>>
                                >>> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                                >>> (unreasonably) convey that the user agent can POST an item of the type
                                >>> communicated by it's current context. This is the problem, I don't need to
                                >>> 'say' to the user-agent that it can POST at a specific URI, because the
                                >>> available HTTP methods tell me what I can do with the resource. What I need
                                >>> to do is examine the permitted methods (either by inspection of the 'Allow'
                                >>> header, or an OPTIONS request) AND not try to convey the permutations of
                                >>> method in the 'rel'.
                                >>>
                                >>> Does that make sense?
                                >>>
                                >>> Thanks in advance
                                >>>
                                >>> Paul
                                >>>
                                >>> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                                >>> <wmartinez@...> wrote:
                                >>>>
                                >>>> Hi nikonguy74!
                                >>>> Just to complement what Jan is saying:
                                >>>> 1. Links represent resources you can work with. The idea of links is that
                                >>>> you can usually follow them (issuing a GET operation), but then there are
                                >>>> lots of questions you may have about them: what do I do with the actual
                                >>>> resource (say, web page) I'm in? What is this link referring to? What
                                >>>> other operations apart from GET can I execute with it? Can I add query
                                >>>> parameters to it? What media type will it return? What media type may it
                                >>>> expect if I can issue a POST?, etc...
                                >>>>
                                >>>> 2. rel is an attribute to add more information about a link. I denotes a
                                >>>> value, keyword, hint of what relation the link has with the current
                                >>>> resource/IRI. Say you are in a book page, that is your current resources
                                >>>> and it has a URI. A link with rel="next" will hint that following that
                                >>>> link will get you to the next page of the book.
                                >>>>
                                >>>> 3. It is important to understand that the rel is the relation the resource
                                >>>> identified by the link's URI, has with the actual resource/uri/document.
                                >>>> It is not good if you use rel to denote other information, like saying
                                >>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                                >>>> to create something. That is not the intended use and it is a bad
                                >>>> practice.
                                >>>>
                                >>>> 4. You may need actual business intelligence in your client. If you are
                                >>>> looking at a blog comment, a rel="parent" will tell you the links points
                                >>>> to the actual blog post. Having that information, you can start asking
                                >>>> that parent for information, or even send a comment to it using POST
                                >>>> operation. That is natural simply because much of this interaction is
                                >>>> already designed in the specs, and the agent may not need to be statically
                                >>>> programmed, but it will need intelligence.
                                >>>>
                                >>>> 5. So, you have there standard metainformation (like how to handle media
                                >>>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                                >>>> Plus, you have business specific semantics (the actual value of the rel
                                >>>> may mean something applicable only to, say, banking applications). With
                                >>>> that info you can program intelligent clients.
                                >>>>
                                >>>> 6. Finally, some other "link" tags like anchor and image are special links
                                >>>> that have a standard meaning and established processing. If you found an
                                >>>> <img> tag you automatically know that link is referring to an image, and
                                >>>> if you are in HTML page in a browser, the supposed processing it to fetch
                                >>>> that image with a GET and display it based on context and additional
                                >>>> attributes. All that is told by the tag name, and everybody in the world
                                >>>> knows it. So, links are difficult to understand at first but once you have
                                >>>> it clear they are simple to use. Only don't expect the link rel attribute
                                >>>> will tell you everything.
                                >>>>
                                >>>> Cheers
                                >>>>
                                >>>> William Martinez.
                                >>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                                >>>> wrote:
                                >>>>>
                                >>>>>
                                >>>>> On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                                >>>>>>
                                >>>>>> I know one of the first questions i had was on rel link. I understand
                                >>>>>> the basic premise behind rel attributes(to provide a general
                                >>>>>> documentation for how to interact with the link provider).
                                >>>>>
                                >>>>> The premise of the rel attribute on links is (in the case of the HTML or
                                >>>>> Atom media types) to provide information about the meaning of the link
                                >>>>> beyond 'this is a link'. If you register your rel name in the IANA
                                >>>>> registry, you can use the short name you registered, e.g. 'next' or
                                >>>>> 'up'. If you did not register your rel, you need to provide a URI.
                                >>>>> Simply for the matter of making your rel unambiguous.
                                >>>>>
                                >>>>> If that URI points to a human readable page explaining the relation,
                                >>>>> then that is even better.
                                >>>>>
                                >>>>> There is no magic (not even in REST :-) that removes the need to
                                >>>>> implement in code (or configure) what the user agent should do when it
                                >>>>> sees your link rel value.
                                >>>>>
                                >>>>> <link rel="http://foo/customerDetails" ... /> is conceptually the same
                                >>>>> as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                                >>>>> AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                                >>>>> user agent needs to be programmed to do something with ... in order to
                                >>>>> have it do something with it.
                                >>>>>
                                >>>>> IOW, your browser downloads that image because it is programmed to do
                                >>>>> so. This same concept also applies to other hypermedia - your user agent
                                >>>>> component will act on the hypermedia it comes across in the way it is
                                >>>>> programmed (or configured) to do.
                                >>>>>
                                >>>>> No magic.
                                >>>>>
                                >>>>> The effect of the hypermedia constraint is actually more felt in the
                                >>>>> obligations you have as a client side programmer (to react to the
                                >>>>> hypermedia you actually come across instead of the one you presume to
                                >>>>> come across) than it is felt in the aspect of loose coupling.
                                >>>>>
                                >>>>> REST mostly makes explicit that there isn't any control over the server
                                >>>>> side in networked systems. REST encourages you to deal with that rather
                                >>>>> than magically solves a problem that cannot be solved. And on top of
                                >>>>> that, REST provides a number of mechanism that optimize for *dealing
                                >>>>> with* the problem (e.g. content negotiation).
                                >>>>>
                                >>>>> HTH,
                                >>>>>
                                >>>>> Jan
                                >>>>>
                                >>>>>> The question is what would you see if you go to the rel link? Is it
                                >>>>>> something a person is suppose to interact with (say to get
                                >>>>>> documentation for new links added to a specific response) or something
                                >>>>>> code can interact with to determine what it needs to do? Unfortunately
                                >>>>>> in the book they don't give an example of what a "rel" page would look
                                >>>>>> like. For example the link:
                                >>>>>> <link rel="http://relations.restbucks.com/payment"
                                >>>>>> href:="http://restbucks.com/payment/1234" />
                                >>>>>>
                                >>>>>> If you typed in "http://relations.restbucks.com/payment" into your web
                                >>>>>> browser what would you see?
                                >>>>>>
                                >>>>>> thanks...
                                >>>>>>
                                >>>>>>
                                >>>>>
                                >>>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>>
                                >>> ------------------------------------
                                >>>
                                >>> Yahoo! Groups Links
                                >>>
                                >>>
                                >>>
                                >
                              • mike amundsen
                                As a follow up affordance designs ideaa. check out this thread from 1997 when Marc Andreesen decided to add support for figures in his Internet Browser . He
                                Message 15 of 23 , May 5, 2012
                                • 0 Attachment
                                  As a follow up affordance designs ideaa. check out this thread from
                                  1997 when Marc Andreesen decided to add support for figures in his
                                  "Internet Browser".

                                  He proposes this[1]:
                                  <IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

                                  Tim Berners-Lee suggests reusing the HTML.A tag[2]:
                                  <a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>

                                  other options are offered including[3]:
                                  <ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">
                                  <INCLUDE HREF="...">
                                  <A HREF="..." INCLUDE>See photo</A>

                                  Which of these options relies on more "out-of-band (not-in-message)"
                                  information?

                                  [1] http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html
                                  [2] http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.html
                                  [3] http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.html

                                  mca
                                  http://amundsen.com/blog/
                                  http://twitter.com@mamund
                                  http://mamund.com/foaf.rdf#me



                                  On Sat, May 5, 2012 at 10:17 AM, mike amundsen <mamund@...> wrote:
                                  > Jørn:
                                  >
                                  > do you think the following design elements are also "bad"?
                                  >
                                  > HTML.IMG
                                  > HTML.A
                                  > HTML.LINK
                                  > HTML.IFRAME
                                  > HTML.SCRIPT
                                  >
                                  > mca
                                  > http://amundsen.com/blog/
                                  > http://twitter.com@mamund
                                  > http://mamund.com/foaf.rdf#me
                                  >
                                  >
                                  >
                                  > On Sat, May 5, 2012 at 8:07 AM, Jørn wildt <jornwildt@...> wrote:
                                  >> In my opinion it is bad. The server should include http method and payload format (but you only asked to compare the two formats). The client should only know the "action" name and the set of parameters to transfer - it is then left to the server to specify the rest in a form language defined by the media type of the current message.
                                  >>
                                  >> /Jørn
                                  >>
                                  >>
                                  >> Sendt fra min iPad
                                  >>
                                  >> Den 05/05/2012 kl. 12.39 skrev mike amundsen <mamund@...>:
                                  >>
                                  >>> note that neither option contains: http method or encoding information.
                                  >>>
                                  >>> that is "out of band" knowledge in these designs.
                                  >>>
                                  >>> is that "good" or "bad" here?
                                  >>>
                                  >>> mca
                                  >>> http://amundsen.com/blog/
                                  >>> http://twitter.com@mamund
                                  >>> http://mamund.com/foaf.rdf#me
                                  >>>
                                  >>>
                                  >>>
                                  >>> On Sat, May 5, 2012 at 6:26 AM, Rushforth, Peter
                                  >>> <peter.rushforth@...> wrote:
                                  >>>> Hi Mike,
                                  >>>>
                                  >>>> A couple of my replies through the yahoo web interface have gone awol.
                                  >>>>
                                  >>>> Thanks for this.
                                  >>>>
                                  >>>> Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
                                  >>>> The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.
                                  >>>>
                                  >>>> Cheers,
                                  >>>> Peter
                                  >>>> ________________________________________
                                  >>>> From: mca@... [mca@...] on behalf of mike amundsen [mamund@...]
                                  >>>> Sent: May 5, 2012 1:04 AM
                                  >>>> To: Jørn Wildt
                                  >>>> Cc: paul_k_moore; Rushforth, Peter; rest-discuss@yahoogroups.com
                                  >>>> Subject: Re: [rest-discuss] Re: Rel attributes?
                                  >>>>
                                  >>>> Jørn, Paul, Peter:
                                  >>>>
                                  >>>> here are two options for a hypermedia affordances in a media type
                                  >>>> design that supports writing new and updating existing resources:
                                  >>>>
                                  >>>> <create href="..." >...</create>
                                  >>>> <update href="...">...</update>
                                  >>>> OR
                                  >>>> <write href="..." action="create">...</write>
                                  >>>> <write href="..." action="update">...</write>
                                  >>>>
                                  >>>> Which relies on more "out-of-band" knowledge?
                                  >>>> Which is a "better" design and why?
                                  >>>>
                                  >>>> mca
                                  >>>> http://amundsen.com/blog/
                                  >>>> http://twitter.com@mamund
                                  >>>> http://mamund.com/foaf.rdf#me
                                  >>>>
                                  >>>>
                                  >>>>
                                  >>>> On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                                  >>>>>>> It is not good if you use rel to denote other information,
                                  >>>>>>> like saying rel="CreateWithPost" to hint the agent to
                                  >>>>>>> use the link's URI with a POST to create something.
                                  >>>>>>> That is not the intended use and it is a bad practice.
                                  >>>>>
                                  >>>>>> It seems reasonable to me, I don't see why it is a bad practice.
                                  >>>>>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                                  >>>>>
                                  >>>>> I would say that you can do rel="CreateWithPost" and declare that in the
                                  >>>>> link-rel documentation. But you loose something by doing so: allowing the
                                  >>>>> server to specify HTTP method and payload encoding at runtime (since that
                                  >>>>> knowledge would have to be a hardcoded part of the link-rel knowledge).
                                  >>>>>
                                  >>>>> Had the link "Create" instead lead to a form of some kind then the form
                                  >>>>> could specifiy HTTP method at runtime, thus letting the server evolve over
                                  >>>>> time (changing HTTP method) without updating the clients (as they are
                                  >>>>> expected to understand the full form language).
                                  >>>>>
                                  >>>>> I haved tried to illustrate this in
                                  >>>>> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                                  >>>>> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                                  >>>>>
                                  >>>>> /Jørn
                                  >>>>>
                                  >>>>> ----- Original Message -----
                                  >>>>> From: Rushforth, Peter
                                  >>>>> To: paul_k_moore
                                  >>>>> Cc: rest-discuss@yahoogroups.com
                                  >>>>> Sent: Friday, May 04, 2012 2:28 PM
                                  >>>>> Subject: RE: [rest-discuss] Re: Rel attributes?
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>> Hi Paul,
                                  >>>>>
                                  >>>>> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                                  >>>>> href.
                                  >>>>>
                                  >>>>> Also in atompub, app:collection/accept/text() tells you you can POST the
                                  >>>>> app:collection/@href whatever MIME types are
                                  >>>>> listed in the app:accept text().
                                  >>>>>
                                  >>>>> Going by that as an exemplar, it seems to me that it is the hypermedia
                                  >>>>> format which is defining what can and can't be
                                  >>>>> done against the URL.  Maybe that is out of band knowledge, but then again,
                                  >>>>> knowing what @method="POST" means
                                  >>>>> could be considered out of band too.   It has to be written down somewhere
                                  >>>>> and agreed to.  So the sharing of the semantics
                                  >>>>> widely is key to interoperability.  Hence a public link relations registry.
                                  >>>>> It is the shared semantics that allows us to
                                  >>>>> program user agents to do predictable things when they come across a
                                  >>>>> particular hypermedia construct.
                                  >>>>>
                                  >>>>> Maybe it is important that when a GET is done on a resource, that the
                                  >>>>> response metadata also declare the available methods.
                                  >>>>> Message metadata is authoritative.
                                  >>>>>
                                  >>>>> But you should not have to do that GET, because it is a waste of bandwidth,
                                  >>>>> and the representation format has already
                                  >>>>> defined (in the registry) and declared (in the instance in which you find
                                  >>>>> the href) the (possibly implicit) method availabilities.
                                  >>>>>
                                  >>>>>> 3. It is important to understand that the rel is the relation the resource
                                  >>>>>> identified by the link's URI, has with the actual resource/uri/document.
                                  >>>>>> It is not good if you use rel to denote other information, like saying
                                  >>>>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                                  >>>>>> to create something. That is not the intended use and it is a bad
                                  >>>>>> practice.
                                  >>>>>
                                  >>>>> It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                                  >>>>> lot like the atom:link@rel="edit", or html's @method="POST".
                                  >>>>>
                                  >>>>> Cheers,
                                  >>>>> Peter
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                                  >>>>> Behalf Of paul_k_moore
                                  >>>>> Sent: May 3, 2012 11:00
                                  >>>>> To: rest-discuss@yahoogroups.com
                                  >>>>> Subject: [rest-discuss] Re: Rel attributes?
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>> William
                                  >>>>>
                                  >>>>> This is very useful - thank you.
                                  >>>>>
                                  >>>>> Just to confirm my (refined) understanding here, I consider the meaning of
                                  >>>>> 'rel' to be an orthogonal concern to the HTTP methods.
                                  >>>>>
                                  >>>>> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                                  >>>>> at the target URI) into the meaning of 'rel'. If we consider the following
                                  >>>>> two examples:
                                  >>>>>
                                  >>>>> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                                  >>>>> reasonably conveys to the user-agent that there is something 'order'-like at
                                  >>>>> the target URI. It is then up to the client (the client intent) to follow
                                  >>>>> this rel (using an implicit GET request) to retrieve the representation of
                                  >>>>> the 'order'-like thing (as rendered in a specific media-type).
                                  >>>>>
                                  >>>>> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                                  >>>>> (unreasonably) convey that the user agent can POST an item of the type
                                  >>>>> communicated by it's current context. This is the problem, I don't need to
                                  >>>>> 'say' to the user-agent that it can POST at a specific URI, because the
                                  >>>>> available HTTP methods tell me what I can do with the resource. What I need
                                  >>>>> to do is examine the permitted methods (either by inspection of the 'Allow'
                                  >>>>> header, or an OPTIONS request) AND not try to convey the permutations of
                                  >>>>> method in the 'rel'.
                                  >>>>>
                                  >>>>> Does that make sense?
                                  >>>>>
                                  >>>>> Thanks in advance
                                  >>>>>
                                  >>>>> Paul
                                  >>>>>
                                  >>>>> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                                  >>>>> <wmartinez@...> wrote:
                                  >>>>>>
                                  >>>>>> Hi nikonguy74!
                                  >>>>>> Just to complement what Jan is saying:
                                  >>>>>> 1. Links represent resources you can work with. The idea of links is that
                                  >>>>>> you can usually follow them (issuing a GET operation), but then there are
                                  >>>>>> lots of questions you may have about them: what do I do with the actual
                                  >>>>>> resource (say, web page) I'm in? What is this link referring to? What
                                  >>>>>> other operations apart from GET can I execute with it? Can I add query
                                  >>>>>> parameters to it? What media type will it return? What media type may it
                                  >>>>>> expect if I can issue a POST?, etc...
                                  >>>>>>
                                  >>>>>> 2. rel is an attribute to add more information about a link. I denotes a
                                  >>>>>> value, keyword, hint of what relation the link has with the current
                                  >>>>>> resource/IRI. Say you are in a book page, that is your current resources
                                  >>>>>> and it has a URI. A link with rel="next" will hint that following that
                                  >>>>>> link will get you to the next page of the book.
                                  >>>>>>
                                  >>>>>> 3. It is important to understand that the rel is the relation the resource
                                  >>>>>> identified by the link's URI, has with the actual resource/uri/document.
                                  >>>>>> It is not good if you use rel to denote other information, like saying
                                  >>>>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                                  >>>>>> to create something. That is not the intended use and it is a bad
                                  >>>>>> practice.
                                  >>>>>>
                                  >>>>>> 4. You may need actual business intelligence in your client. If you are
                                  >>>>>> looking at a blog comment, a rel="parent" will tell you the links points
                                  >>>>>> to the actual blog post. Having that information, you can start asking
                                  >>>>>> that parent for information, or even send a comment to it using POST
                                  >>>>>> operation. That is natural simply because much of this interaction is
                                  >>>>>> already designed in the specs, and the agent may not need to be statically
                                  >>>>>> programmed, but it will need intelligence.
                                  >>>>>>
                                  >>>>>> 5. So, you have there standard metainformation (like how to handle media
                                  >>>>>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                                  >>>>>> Plus, you have business specific semantics (the actual value of the rel
                                  >>>>>> may mean something applicable only to, say, banking applications). With
                                  >>>>>> that info you can program intelligent clients.
                                  >>>>>>
                                  >>>>>> 6. Finally, some other "link" tags like anchor and image are special links
                                  >>>>>> that have a standard meaning and established processing. If you found an
                                  >>>>>> <img> tag you automatically know that link is referring to an image, and
                                  >>>>>> if you are in HTML page in a browser, the supposed processing it to fetch
                                  >>>>>> that image with a GET and display it based on context and additional
                                  >>>>>> attributes. All that is told by the tag name, and everybody in the world
                                  >>>>>> knows it. So, links are difficult to understand at first but once you have
                                  >>>>>> it clear they are simple to use. Only don't expect the link rel attribute
                                  >>>>>> will tell you everything.
                                  >>>>>>
                                  >>>>>> Cheers
                                  >>>>>>
                                  >>>>>> William Martinez.
                                  >>>>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                                  >>>>>> wrote:
                                  >>>>>>>
                                  >>>>>>>
                                  >>>>>>> On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                                  >>>>>>>>
                                  >>>>>>>> I know one of the first questions i had was on rel link. I understand
                                  >>>>>>>> the basic premise behind rel attributes(to provide a general
                                  >>>>>>>> documentation for how to interact with the link provider).
                                  >>>>>>>
                                  >>>>>>> The premise of the rel attribute on links is (in the case of the HTML or
                                  >>>>>>> Atom media types) to provide information about the meaning of the link
                                  >>>>>>> beyond 'this is a link'. If you register your rel name in the IANA
                                  >>>>>>> registry, you can use the short name you registered, e.g. 'next' or
                                  >>>>>>> 'up'. If you did not register your rel, you need to provide a URI.
                                  >>>>>>> Simply for the matter of making your rel unambiguous.
                                  >>>>>>>
                                  >>>>>>> If that URI points to a human readable page explaining the relation,
                                  >>>>>>> then that is even better.
                                  >>>>>>>
                                  >>>>>>> There is no magic (not even in REST :-) that removes the need to
                                  >>>>>>> implement in code (or configure) what the user agent should do when it
                                  >>>>>>> sees your link rel value.
                                  >>>>>>>
                                  >>>>>>> <link rel="http://foo/customerDetails" ... /> is conceptually the same
                                  >>>>>>> as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                                  >>>>>>> AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                                  >>>>>>> user agent needs to be programmed to do something with ... in order to
                                  >>>>>>> have it do something with it.
                                  >>>>>>>
                                  >>>>>>> IOW, your browser downloads that image because it is programmed to do
                                  >>>>>>> so. This same concept also applies to other hypermedia - your user agent
                                  >>>>>>> component will act on the hypermedia it comes across in the way it is
                                  >>>>>>> programmed (or configured) to do.
                                  >>>>>>>
                                  >>>>>>> No magic.
                                  >>>>>>>
                                  >>>>>>> The effect of the hypermedia constraint is actually more felt in the
                                  >>>>>>> obligations you have as a client side programmer (to react to the
                                  >>>>>>> hypermedia you actually come across instead of the one you presume to
                                  >>>>>>> come across) than it is felt in the aspect of loose coupling.
                                  >>>>>>>
                                  >>>>>>> REST mostly makes explicit that there isn't any control over the server
                                  >>>>>>> side in networked systems. REST encourages you to deal with that rather
                                  >>>>>>> than magically solves a problem that cannot be solved. And on top of
                                  >>>>>>> that, REST provides a number of mechanism that optimize for *dealing
                                  >>>>>>> with* the problem (e.g. content negotiation).
                                  >>>>>>>
                                  >>>>>>> HTH,
                                  >>>>>>>
                                  >>>>>>> Jan
                                  >>>>>>>
                                  >>>>>>>> The question is what would you see if you go to the rel link? Is it
                                  >>>>>>>> something a person is suppose to interact with (say to get
                                  >>>>>>>> documentation for new links added to a specific response) or something
                                  >>>>>>>> code can interact with to determine what it needs to do? Unfortunately
                                  >>>>>>>> in the book they don't give an example of what a "rel" page would look
                                  >>>>>>>> like. For example the link:
                                  >>>>>>>> <link rel="http://relations.restbucks.com/payment"
                                  >>>>>>>> href:="http://restbucks.com/payment/1234" />
                                  >>>>>>>>
                                  >>>>>>>> If you typed in "http://relations.restbucks.com/payment" into your web
                                  >>>>>>>> browser what would you see?
                                  >>>>>>>>
                                  >>>>>>>> thanks...
                                  >>>>>>>>
                                  >>>>>>>>
                                  >>>>>>>
                                  >>>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>> ------------------------------------
                                  >>>>>
                                  >>>>> Yahoo! Groups Links
                                  >>>>>
                                  >>>>>
                                  >>>>>
                                  >>>>
                                  >>>>
                                  >>>> ------------------------------------
                                  >>>>
                                  >>>> Yahoo! Groups Links
                                  >>>>
                                  >>>>
                                  >>>>
                                • mike amundsen
                                  Jørn: what i am aiming for is judgement. as designers of solutions (architects, programmers, implementors, etc.) we make decisions. we decide to use one
                                  Message 16 of 23 , May 5, 2012
                                  • 0 Attachment
                                    Jørn:

                                    what i am aiming for is judgement. as designers of solutions
                                    (architects, programmers, implementors, etc.) we make decisions. we
                                    decide to use one option over another. we decide some set of possible
                                    options are [fill in some word that is more acceptable for you than
                                    "bad" here] and one of the possible options is "good" (or some other
                                    word you find acceptable).

                                    FWIW, what i am after here is to give us all a chance to talk about
                                    our choices. i've not used words like "right" "wrong" here. i've been
                                    careful to use several important words with quote marks around them to
                                    indicate that those words have a qualitative value, not quantitative.
                                    i've provided more than one possible ways to interpret and answer the
                                    questions i pose.

                                    what i am doing here is offering choices that are, essentially,
                                    functional equivalents. some would select one option; some another. i
                                    am asking for ppl to make explicit their choices and help me learn why
                                    they made them.

                                    for me, there is no "right" answer. and every answer is an opportunity
                                    for me to learn.

                                    i hope this helps you understand why i am asking these questions in
                                    this particular way.

                                    mca
                                    http://amundsen.com/blog/
                                    http://twitter.com@mamund
                                    http://mamund.com/foaf.rdf#me



                                    On Sat, May 5, 2012 at 2:09 PM, Jørn wildt <jornwildt@...> wrote:
                                    > Mike, lets drop the word "bad", my trouble in the first question was more about missing flexibility for an update operation, and as I pointed out, you loose something by not letting the server specify http mehtod - but that doesn't make it "bad".
                                    >
                                    > So, to answer your question, no, none of these are "bad" and neither of them has anything to do with updating. What are you aiming for?
                                    >
                                    > /Jørn
                                    >
                                    > Den 05/05/2012 kl. 16.17 skrev mike amundsen <mamund@...>:
                                    >
                                    >> Jørn:
                                    >>
                                    >> do you think the following design elements are also "bad"?
                                    >>
                                    >> HTML.IMG
                                    >> HTML.A
                                    >> HTML.LINK
                                    >> HTML.IFRAME
                                    >> HTML.SCRIPT
                                    >>
                                    >> mca
                                    >> http://amundsen.com/blog/
                                    >> http://twitter.com@mamund
                                    >> http://mamund.com/foaf.rdf#me
                                    >>
                                    >>
                                    >>
                                    >> On Sat, May 5, 2012 at 8:07 AM, Jørn wildt <jornwildt@...> wrote:
                                    >>> In my opinion it is bad. The server should include http method and payload format (but you only asked to compare the two formats). The client should only know the "action" name and the set of parameters to transfer - it is then left to the server to specify the rest in a form language defined by the media type of the current message.
                                    >>>
                                    >>> /Jørn
                                    >>>
                                    >>>
                                    >>> Sendt fra min iPad
                                    >>>
                                    >>> Den 05/05/2012 kl. 12.39 skrev mike amundsen <mamund@...>:
                                    >>>
                                    >>>> note that neither option contains: http method or encoding information.
                                    >>>>
                                    >>>> that is "out of band" knowledge in these designs.
                                    >>>>
                                    >>>> is that "good" or "bad" here?
                                    >>>>
                                    >>>> mca
                                    >>>> http://amundsen.com/blog/
                                    >>>> http://twitter.com@mamund
                                    >>>> http://mamund.com/foaf.rdf#me
                                    >>>>
                                    >>>>
                                    >>>>
                                    >>>> On Sat, May 5, 2012 at 6:26 AM, Rushforth, Peter
                                    >>>> <peter.rushforth@...> wrote:
                                    >>>>> Hi Mike,
                                    >>>>>
                                    >>>>> A couple of my replies through the yahoo web interface have gone awol.
                                    >>>>>
                                    >>>>> Thanks for this.
                                    >>>>>
                                    >>>>> Both rely on the hypermedia documentation, per Roy's hypermedia-apis-must-be-hypertext-driven post.
                                    >>>>> The first option is simpler, so it gets my vote, in the absence of a defined use for the extra markup.
                                    >>>>>
                                    >>>>> Cheers,
                                    >>>>> Peter
                                    >>>>> ________________________________________
                                    >>>>> From: mca@... [mca@...] on behalf of mike amundsen [mamund@...]
                                    >>>>> Sent: May 5, 2012 1:04 AM
                                    >>>>> To: Jørn Wildt
                                    >>>>> Cc: paul_k_moore; Rushforth, Peter; rest-discuss@yahoogroups.com
                                    >>>>> Subject: Re: [rest-discuss] Re: Rel attributes?
                                    >>>>>
                                    >>>>> Jørn, Paul, Peter:
                                    >>>>>
                                    >>>>> here are two options for a hypermedia affordances in a media type
                                    >>>>> design that supports writing new and updating existing resources:
                                    >>>>>
                                    >>>>> <create href="..." >...</create>
                                    >>>>> <update href="...">...</update>
                                    >>>>> OR
                                    >>>>> <write href="..." action="create">...</write>
                                    >>>>> <write href="..." action="update">...</write>
                                    >>>>>
                                    >>>>> Which relies on more "out-of-band" knowledge?
                                    >>>>> Which is a "better" design and why?
                                    >>>>>
                                    >>>>> mca
                                    >>>>> http://amundsen.com/blog/
                                    >>>>> http://twitter.com@mamund
                                    >>>>> http://mamund.com/foaf.rdf#me
                                    >>>>>
                                    >>>>>
                                    >>>>>
                                    >>>>> On Fri, May 4, 2012 at 4:45 PM, Jørn Wildt <jw@...> wrote:
                                    >>>>>>>> It is not good if you use rel to denote other information,
                                    >>>>>>>> like saying rel="CreateWithPost" to hint the agent to
                                    >>>>>>>> use the link's URI with a POST to create something.
                                    >>>>>>>> That is not the intended use and it is a bad practice.
                                    >>>>>>
                                    >>>>>>> It seems reasonable to me, I don't see why it is a bad practice.
                                    >>>>>>> It looks a lot like the atom:link@rel="edit", or html's @method="POST".
                                    >>>>>>
                                    >>>>>> I would say that you can do rel="CreateWithPost" and declare that in the
                                    >>>>>> link-rel documentation. But you loose something by doing so: allowing the
                                    >>>>>> server to specify HTTP method and payload encoding at runtime (since that
                                    >>>>>> knowledge would have to be a hardcoded part of the link-rel knowledge).
                                    >>>>>>
                                    >>>>>> Had the link "Create" instead lead to a form of some kind then the form
                                    >>>>>> could specifiy HTTP method at runtime, thus letting the server evolve over
                                    >>>>>> time (changing HTTP method) without updating the clients (as they are
                                    >>>>>> expected to understand the full form language).
                                    >>>>>>
                                    >>>>>> I haved tried to illustrate this in
                                    >>>>>> https://groups.google.com/d/msg/hypermedia-web/mtdVPRks_QI/ZEK3_9QBVtoJ -
                                    >>>>>> check the "evolving server, stable client" scenarios in example 1, 2 and 3.
                                    >>>>>>
                                    >>>>>> /Jørn
                                    >>>>>>
                                    >>>>>> ----- Original Message -----
                                    >>>>>> From: Rushforth, Peter
                                    >>>>>> To: paul_k_moore
                                    >>>>>> Cc: rest-discuss@yahoogroups.com
                                    >>>>>> Sent: Friday, May 04, 2012 2:28 PM
                                    >>>>>> Subject: RE: [rest-discuss] Re: Rel attributes?
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>> Hi Paul,
                                    >>>>>>
                                    >>>>>> In atompub, the rel="edit" link relation means you can PUT or DELETE to the
                                    >>>>>> href.
                                    >>>>>>
                                    >>>>>> Also in atompub, app:collection/accept/text() tells you you can POST the
                                    >>>>>> app:collection/@href whatever MIME types are
                                    >>>>>> listed in the app:accept text().
                                    >>>>>>
                                    >>>>>> Going by that as an exemplar, it seems to me that it is the hypermedia
                                    >>>>>> format which is defining what can and can't be
                                    >>>>>> done against the URL.  Maybe that is out of band knowledge, but then again,
                                    >>>>>> knowing what @method="POST" means
                                    >>>>>> could be considered out of band too.   It has to be written down somewhere
                                    >>>>>> and agreed to.  So the sharing of the semantics
                                    >>>>>> widely is key to interoperability.  Hence a public link relations registry.
                                    >>>>>> It is the shared semantics that allows us to
                                    >>>>>> program user agents to do predictable things when they come across a
                                    >>>>>> particular hypermedia construct.
                                    >>>>>>
                                    >>>>>> Maybe it is important that when a GET is done on a resource, that the
                                    >>>>>> response metadata also declare the available methods.
                                    >>>>>> Message metadata is authoritative.
                                    >>>>>>
                                    >>>>>> But you should not have to do that GET, because it is a waste of bandwidth,
                                    >>>>>> and the representation format has already
                                    >>>>>> defined (in the registry) and declared (in the instance in which you find
                                    >>>>>> the href) the (possibly implicit) method availabilities.
                                    >>>>>>
                                    >>>>>>> 3. It is important to understand that the rel is the relation the resource
                                    >>>>>>> identified by the link's URI, has with the actual resource/uri/document.
                                    >>>>>>> It is not good if you use rel to denote other information, like saying
                                    >>>>>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                                    >>>>>>> to create something. That is not the intended use and it is a bad
                                    >>>>>>> practice.
                                    >>>>>>
                                    >>>>>> It seems reasonable to me, I don't see why it is a bad practice.  It looks a
                                    >>>>>> lot like the atom:link@rel="edit", or html's @method="POST".
                                    >>>>>>
                                    >>>>>> Cheers,
                                    >>>>>> Peter
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>> From: rest-discuss@yahoogroups.com [mailto:rest-discuss@yahoogroups.com] On
                                    >>>>>> Behalf Of paul_k_moore
                                    >>>>>> Sent: May 3, 2012 11:00
                                    >>>>>> To: rest-discuss@yahoogroups.com
                                    >>>>>> Subject: [rest-discuss] Re: Rel attributes?
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>> William
                                    >>>>>>
                                    >>>>>> This is very useful - thank you.
                                    >>>>>>
                                    >>>>>> Just to confirm my (refined) understanding here, I consider the meaning of
                                    >>>>>> 'rel' to be an orthogonal concern to the HTTP methods.
                                    >>>>>>
                                    >>>>>> To expound slightly, I had erroneously conflated the HTTP methods (avaialble
                                    >>>>>> at the target URI) into the meaning of 'rel'. If we consider the following
                                    >>>>>> two examples:
                                    >>>>>>
                                    >>>>>> Example 1: Use of a 'rel' such as 'http://relations.example.com/order'
                                    >>>>>> reasonably conveys to the user-agent that there is something 'order'-like at
                                    >>>>>> the target URI. It is then up to the client (the client intent) to follow
                                    >>>>>> this rel (using an implicit GET request) to retrieve the representation of
                                    >>>>>> the 'order'-like thing (as rendered in a specific media-type).
                                    >>>>>>
                                    >>>>>> Example 2: Use of a 'rel' such as 'http://relations.example.com/new' to
                                    >>>>>> (unreasonably) convey that the user agent can POST an item of the type
                                    >>>>>> communicated by it's current context. This is the problem, I don't need to
                                    >>>>>> 'say' to the user-agent that it can POST at a specific URI, because the
                                    >>>>>> available HTTP methods tell me what I can do with the resource. What I need
                                    >>>>>> to do is examine the permitted methods (either by inspection of the 'Allow'
                                    >>>>>> header, or an OPTIONS request) AND not try to convey the permutations of
                                    >>>>>> method in the 'rel'.
                                    >>>>>>
                                    >>>>>> Does that make sense?
                                    >>>>>>
                                    >>>>>> Thanks in advance
                                    >>>>>>
                                    >>>>>> Paul
                                    >>>>>>
                                    >>>>>> --- In rest-discuss@yahoogroups.com, "William Martinez Pomares"
                                    >>>>>> <wmartinez@...> wrote:
                                    >>>>>>>
                                    >>>>>>> Hi nikonguy74!
                                    >>>>>>> Just to complement what Jan is saying:
                                    >>>>>>> 1. Links represent resources you can work with. The idea of links is that
                                    >>>>>>> you can usually follow them (issuing a GET operation), but then there are
                                    >>>>>>> lots of questions you may have about them: what do I do with the actual
                                    >>>>>>> resource (say, web page) I'm in? What is this link referring to? What
                                    >>>>>>> other operations apart from GET can I execute with it? Can I add query
                                    >>>>>>> parameters to it? What media type will it return? What media type may it
                                    >>>>>>> expect if I can issue a POST?, etc...
                                    >>>>>>>
                                    >>>>>>> 2. rel is an attribute to add more information about a link. I denotes a
                                    >>>>>>> value, keyword, hint of what relation the link has with the current
                                    >>>>>>> resource/IRI. Say you are in a book page, that is your current resources
                                    >>>>>>> and it has a URI. A link with rel="next" will hint that following that
                                    >>>>>>> link will get you to the next page of the book.
                                    >>>>>>>
                                    >>>>>>> 3. It is important to understand that the rel is the relation the resource
                                    >>>>>>> identified by the link's URI, has with the actual resource/uri/document.
                                    >>>>>>> It is not good if you use rel to denote other information, like saying
                                    >>>>>>> rel="CreateWithPost" to hint the agent to use the link's URI with a POST
                                    >>>>>>> to create something. That is not the intended use and it is a bad
                                    >>>>>>> practice.
                                    >>>>>>>
                                    >>>>>>> 4. You may need actual business intelligence in your client. If you are
                                    >>>>>>> looking at a blog comment, a rel="parent" will tell you the links points
                                    >>>>>>> to the actual blog post. Having that information, you can start asking
                                    >>>>>>> that parent for information, or even send a comment to it using POST
                                    >>>>>>> operation. That is natural simply because much of this interaction is
                                    >>>>>>> already designed in the specs, and the agent may not need to be statically
                                    >>>>>>> programmed, but it will need intelligence.
                                    >>>>>>>
                                    >>>>>>> 5. So, you have there standard metainformation (like how to handle media
                                    >>>>>>> types, the semantics of POST and PUT, the semantics or link and rel), etc.
                                    >>>>>>> Plus, you have business specific semantics (the actual value of the rel
                                    >>>>>>> may mean something applicable only to, say, banking applications). With
                                    >>>>>>> that info you can program intelligent clients.
                                    >>>>>>>
                                    >>>>>>> 6. Finally, some other "link" tags like anchor and image are special links
                                    >>>>>>> that have a standard meaning and established processing. If you found an
                                    >>>>>>> <img> tag you automatically know that link is referring to an image, and
                                    >>>>>>> if you are in HTML page in a browser, the supposed processing it to fetch
                                    >>>>>>> that image with a GET and display it based on context and additional
                                    >>>>>>> attributes. All that is told by the tag name, and everybody in the world
                                    >>>>>>> knows it. So, links are difficult to understand at first but once you have
                                    >>>>>>> it clear they are simple to use. Only don't expect the link rel attribute
                                    >>>>>>> will tell you everything.
                                    >>>>>>>
                                    >>>>>>> Cheers
                                    >>>>>>>
                                    >>>>>>> William Martinez.
                                    >>>>>>> --- In rest-discuss@yahoogroups.com, Jan Algermissen <jan.algermissen@>
                                    >>>>>>> wrote:
                                    >>>>>>>>
                                    >>>>>>>>
                                    >>>>>>>> On Mar 19, 2012, at 6:40 PM, nikonguy74 wrote:
                                    >>>>>>>>>
                                    >>>>>>>>> I know one of the first questions i had was on rel link. I understand
                                    >>>>>>>>> the basic premise behind rel attributes(to provide a general
                                    >>>>>>>>> documentation for how to interact with the link provider).
                                    >>>>>>>>
                                    >>>>>>>> The premise of the rel attribute on links is (in the case of the HTML or
                                    >>>>>>>> Atom media types) to provide information about the meaning of the link
                                    >>>>>>>> beyond 'this is a link'. If you register your rel name in the IANA
                                    >>>>>>>> registry, you can use the short name you registered, e.g. 'next' or
                                    >>>>>>>> 'up'. If you did not register your rel, you need to provide a URI.
                                    >>>>>>>> Simply for the matter of making your rel unambiguous.
                                    >>>>>>>>
                                    >>>>>>>> If that URI points to a human readable page explaining the relation,
                                    >>>>>>>> then that is even better.
                                    >>>>>>>>
                                    >>>>>>>> There is no magic (not even in REST :-) that removes the need to
                                    >>>>>>>> implement in code (or configure) what the user agent should do when it
                                    >>>>>>>> sees your link rel value.
                                    >>>>>>>>
                                    >>>>>>>> <link rel="http://foo/customerDetails" ... /> is conceptually the same
                                    >>>>>>>> as <link rel="working-copy" .../> and also as HTML's <img src="..."/> or
                                    >>>>>>>> AtomPub's <collection href="..."/>. It is just hypermedia ... that a
                                    >>>>>>>> user agent needs to be programmed to do something with ... in order to
                                    >>>>>>>> have it do something with it.
                                    >>>>>>>>
                                    >>>>>>>> IOW, your browser downloads that image because it is programmed to do
                                    >>>>>>>> so. This same concept also applies to other hypermedia - your user agent
                                    >>>>>>>> component will act on the hypermedia it comes across in the way it is
                                    >>>>>>>> programmed (or configured) to do.
                                    >>>>>>>>
                                    >>>>>>>> No magic.
                                    >>>>>>>>
                                    >>>>>>>> The effect of the hypermedia constraint is actually more felt in the
                                    >>>>>>>> obligations you have as a client side programmer (to react to the
                                    >>>>>>>> hypermedia you actually come across instead of the one you presume to
                                    >>>>>>>> come across) than it is felt in the aspect of loose coupling.
                                    >>>>>>>>
                                    >>>>>>>> REST mostly makes explicit that there isn't any control over the server
                                    >>>>>>>> side in networked systems. REST encourages you to deal with that rather
                                    >>>>>>>> than magically solves a problem that cannot be solved. And on top of
                                    >>>>>>>> that, REST provides a number of mechanism that optimize for *dealing
                                    >>>>>>>> with* the problem (e.g. content negotiation).
                                    >>>>>>>>
                                    >>>>>>>> HTH,
                                    >>>>>>>>
                                    >>>>>>>> Jan
                                    >>>>>>>>
                                    >>>>>>>>> The question is what would you see if you go to the rel link? Is it
                                    >>>>>>>>> something a person is suppose to interact with (say to get
                                    >>>>>>>>> documentation for new links added to a specific response) or something
                                    >>>>>>>>> code can interact with to determine what it needs to do? Unfortunately
                                    >>>>>>>>> in the book they don't give an example of what a "rel" page would look
                                    >>>>>>>>> like. For example the link:
                                    >>>>>>>>> <link rel="http://relations.restbucks.com/payment"
                                    >>>>>>>>> href:="http://restbucks.com/payment/1234" />
                                    >>>>>>>>>
                                    >>>>>>>>> If you typed in "http://relations.restbucks.com/payment" into your web
                                    >>>>>>>>> browser what would you see?
                                    >>>>>>>>>
                                    >>>>>>>>> thanks...
                                    >>>>>>>>>
                                    >>>>>>>>>
                                    >>>>>>>>
                                    >>>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>> ------------------------------------
                                    >>>>>>
                                    >>>>>> Yahoo! Groups Links
                                    >>>>>>
                                    >>>>>>
                                    >>>>>>
                                    >>>>>
                                    >>>>>
                                    >>>>> ------------------------------------
                                    >>>>>
                                    >>>>> Yahoo! Groups Links
                                    >>>>>
                                    >>>>>
                                    >>>>>
                                  Your message has been successfully submitted and would be delivered to recipients shortly.