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

16980Re: [rest-discuss] Link relations [was: A media type for case files, dossiers and documents]

Expand Messages
  • Trygve Laugstøl
    Dec 1, 2010
    • 0 Attachment
      On 11/30/10 7:26 PM, Peter Williams wrote:
      > On Tue, Nov 30, 2010 at 11:07 AM, Trygve Laugstøl<trygvis@...> wrote:
      >> On 11/30/10 6:38 PM, Peter Williams wrote:
      >>>
      >>> 2010/11/30 Trygve Laugstųl<trygvis@...>:
      >>>
      >>>> I would go for atom:link as I hope that everyone will converge on using
      >>>> atom:link [1]. The main advantage as I see it is that they will have
      >>>> less to learn and that we will will converge on a more stable set of
      >>>> relations which in turn will make it possible to create more generic
      >>>> code for indexing, crawling etc. Just make sure you create and define
      >>>> your own rel types according to the atom spec [2].
      >>>
      >>> Personally i don't much like atom:link. It trades clarity for a false
      >>> promise of re-use. The idea that a great deal of leverage will be
      >>> gained by reusing atom:link in other formats seems not be born out in
      >>> reality. Parsing arbitrary xml documents, looking for link elements
      >>> and then doing things with them without understanding the semantics of
      >>> the overall representation sounds pretty far fetched to me. (Is that
      >>> edit link for the requested resource, or is it for a different
      >>> resource whose information is contained in the requested one.)
      >>>
      >>> The `<{name} href=""/>` pattern promotes the meaningful name of the
      >>> item to the highest possible level. This increases the clarity of the
      >>> representation. As a client writer i care about semantics of the
      >>> various parts of the representations far more than i care about their
      >>> types. I can guess with little effort that an element named 'edit'
      >>> will contain a link. With a link element i must scan to the right
      >>> until i find the @rel in order to understand the purpose of the
      >>> element. I'll take clarity over vague, unrealistic, promises of
      >>> re-use any day.
      >>
      >> To me<atom:link rel="{name}" href=""/> is equal to<{name} href=""/>.
      >
      > I agree they are semantically equivalent. However, the arrangement of
      > information in an atom:link element increases the effort required to
      > understand it. Not much of course, but a little. I prefer not to
      > intentionally increase the complexity of my representations unless it
      > provide a very real benefit.

      I'm not sure I understand what you mean by "arrangement of information".
      Do you mean that they have to go and read the Atom specification?

      >>> Besides, we have the link header[1] which is better, in every
      >>> imaginable way, than atom:link for expressing common relations. It
      >>> does not require the client be able to parse a particular format and
      >>> it unambiguously relates the link to the requested resource as a
      >>> whole.
      >>
      >>>
      >>>
      >>> [1]:<http://tools.ietf.org/html/rfc5988>
      >>
      >> Link headers is mostly useful for linking *entire resources* to other
      >> *resources* while atom:link gives you a more fine grained linking mechanism.
      >> I'm not against link headers in anyway, just saying it's a slightly
      >> different thing.
      >
      > Exactly. The ambiguity of link elements (due to their fine
      > grainedness) works against any real world re-use of them. Clien have
      > to understand the whole representation that contains link elements in
      > order to use those links. Therefore, there is little, or no,
      > practical benefit to using atom:link elements but there is some cost.

      I'm not sure I understand what you mean here. What I'm saying that
      instead of using your own <FooLink> you use should consider using
      <atom:link>. Link headers really doesn't have anything to do with Atom's
      link element type.

      --
      Trygve
    • Show all 88 messages in this topic