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

discovering "alternate" representations?

Expand Messages
  • Kristian Rink
    Folks; trying to build REST resources that make heavy use of delivering different representations of binary files, I ended up looking for thoughts on how to
    Message 1 of 8 , Oct 4, 2012
    • 0 Attachment
      Folks;

      trying to build REST resources that make heavy use of delivering
      different representations of binary files, I ended up looking for
      thoughts on how to deal with alternate representations of a resource in
      different media types.

      To outline the issue in a simple example: Imagine instructions on how to
      assemble a piece of furniture bought in some large store. These
      instructions are made available, say, as "text/html" (written
      description of what to do), "application/pdf" (step-by-step instructions
      in illustrations) and "application/mp4" (video showing what needs to be
      done).

      All the things basically represent the same resource, the same content,
      in just different representations. There's two things that make me think:

      - As far as I understood content negotiation by now, this is sort of a
      client-driven procedure: Client provides a more or less lengthy weighted
      Accept: header, server delivers the kind of representation content type
      that seems to suit the client best, based upon Accept:, language, and of
      course the kind of stuff the server is capable of providing, after all.
      While this is neat when making client and server quietly make up whether
      to transfer and render image/gif or image/png, it seems to fall short in
      a case as the one outlined before. Here, I would kind of expect a
      standards based approach allowing for the client to determine which kind
      of representations a server is capable to provide, to by then know
      "there's text, there's a pdf, and there's a video clip of the same
      content, too". What is the best way of dealing with such a requirement,
      both in terms of interoperability and in terms of "clean-ness of design"?

      - Right now, I make use of Atom <entry>'s and rel="alternate" links to
      keep such things together. Apart from at least _feeling_ a bit strange
      (now the different "representations" of the same thing are linked as
      "alternate" from an Atom <entry> which does not represent but just
      describe that actual resource) I am left with another question: Right
      now, with this approach, I easily can provide a client system with the
      information which media type representations are available for that very
      resource. However this just (obviously) works whenever accessing the
      <entry> resource first, to by then see a structure like

      http://.../documentation/how-to-build-that-table

      having link rel="alternate" to

      http://.../documentation/how-to-build-that-table/file.mp4
      http://.../documentation/how-to-build-that-table/file.pdf
      http://.../documentation/how-to-build-that-table/file.txt

      which works. However, in such a situation, to tell which alternate
      representations are there, I always will have to access the

      http://.../documentation/how-to-build-that-table

      resource first, which means that I have to know this one. I so far
      haven't figured out an obvious, portable way how to, in example starting
      out with the "application/pdf" representation, tell that there are
      alternative media type representations available, as well.

      Hmm. Maybe I am missing something essential / fundamental / trivial
      about that, or I made a fundamental mistake in thinking about my
      resource design. Inspirations / thoughts, anyone?

      TIA and all the best,
      Kristian
    • Erik Wilde
      RFC 6596, maybe? cheers, dret. ... -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 |
      Message 2 of 8 , Oct 4, 2012
      • 0 Attachment
        RFC 6596, maybe? cheers, dret.

        On 2012-10-04 11:28 , Kristian Rink wrote:
        > Folks;
        >
        > trying to build REST resources that make heavy use of delivering
        > different representations of binary files, I ended up looking for
        > thoughts on how to deal with alternate representations of a resource in
        > different media types.
        >
        > To outline the issue in a simple example: Imagine instructions on how to
        > assemble a piece of furniture bought in some large store. These
        > instructions are made available, say, as "text/html" (written
        > description of what to do), "application/pdf" (step-by-step instructions
        > in illustrations) and "application/mp4" (video showing what needs to be
        > done).
        >
        > All the things basically represent the same resource, the same content,
        > in just different representations. There's two things that make me think:
        >
        > - As far as I understood content negotiation by now, this is sort of a
        > client-driven procedure: Client provides a more or less lengthy weighted
        > Accept: header, server delivers the kind of representation content type
        > that seems to suit the client best, based upon Accept:, language, and of
        > course the kind of stuff the server is capable of providing, after all.
        > While this is neat when making client and server quietly make up whether
        > to transfer and render image/gif or image/png, it seems to fall short in
        > a case as the one outlined before. Here, I would kind of expect a
        > standards based approach allowing for the client to determine which kind
        > of representations a server is capable to provide, to by then know
        > "there's text, there's a pdf, and there's a video clip of the same
        > content, too". What is the best way of dealing with such a requirement,
        > both in terms of interoperability and in terms of "clean-ness of design"?
        >
        > - Right now, I make use of Atom <entry>'s and rel="alternate" links to
        > keep such things together. Apart from at least _feeling_ a bit strange
        > (now the different "representations" of the same thing are linked as
        > "alternate" from an Atom <entry> which does not represent but just
        > describe that actual resource) I am left with another question: Right
        > now, with this approach, I easily can provide a client system with the
        > information which media type representations are available for that very
        > resource. However this just (obviously) works whenever accessing the
        > <entry> resource first, to by then see a structure like
        >
        > http://.../documentation/how-to-build-that-table
        >
        > having link rel="alternate" to
        >
        > http://.../documentation/how-to-build-that-table/file.mp4
        > http://.../documentation/how-to-build-that-table/file.pdf
        > http://.../documentation/how-to-build-that-table/file.txt
        >
        > which works. However, in such a situation, to tell which alternate
        > representations are there, I always will have to access the
        >
        > http://.../documentation/how-to-build-that-table
        >
        > resource first, which means that I have to know this one. I so far
        > haven't figured out an obvious, portable way how to, in example starting
        > out with the "application/pdf" representation, tell that there are
        > alternative media type representations available, as well.
        >
        > Hmm. Maybe I am missing something essential / fundamental / trivial
        > about that, or I made a fundamental mistake in thinking about my
        > resource design. Inspirations / thoughts, anyone?
        >
        > TIA and all the best,
        > Kristian
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >

        --
        erik wilde | mailto:dret@... - tel:+1-510-2061079 |
        | UC Berkeley - School of Information (ISchool) |
        | http://dret.net/netdret http://twitter.com/dret |
      • mike amundsen
        consider: 1) use link headers with the response that return the list of all other representations for the current response (work on rel values for this) 2)
        Message 3 of 8 , Oct 4, 2012
        • 0 Attachment
          consider:

          1) use link headers with the response that return the list of all other representations for the current response (work on rel values for this)

          2) support for an OPTIONS call for the current URI that return the list of possible reprsentations for the current response

          3) arrange a client-drive negotiation model where the server returns 300 w/ a list of possible representations and the client picks which it wants this time

          each has pros/cons, but none of the options are dependent upon a particular media type or canonical URI as a starting point.

          hope this gives you some ideas.

          mca+1.859.757.1449
          skype: mca.amundsen
          http://amundsen.com/blog/
          http://twitter.com/mamund
          https://github.com/mamund
          http://www.linkedin.com/in/mikeamundsen


          On Thu, Oct 4, 2012 at 8:06 PM, Erik Wilde <dret@...> wrote:
          RFC 6596, maybe? cheers, dret.

          On 2012-10-04 11:28 , Kristian Rink wrote:
          > Folks;
          >
          > trying to build REST resources that make heavy use of delivering
          > different representations of binary files, I ended up looking for
          > thoughts on how to deal with alternate representations of a resource in
          > different media types.
          >
          > To outline the issue in a simple example: Imagine instructions on how to
          > assemble a piece of furniture bought in some large store. These
          > instructions are made available, say, as "text/html" (written
          > description of what to do), "application/pdf" (step-by-step instructions
          > in illustrations) and "application/mp4" (video showing what needs to be
          > done).
          >
          > All the things basically represent the same resource, the same content,
          > in just different representations. There's two things that make me think:
          >
          > - As far as I understood content negotiation by now, this is sort of a
          > client-driven procedure: Client provides a more or less lengthy weighted
          > Accept: header, server delivers the kind of representation content type
          > that seems to suit the client best, based upon Accept:, language, and of
          > course the kind of stuff the server is capable of providing, after all.
          > While this is neat when making client and server quietly make up whether
          > to transfer and render image/gif or image/png, it seems to fall short in
          > a case as the one outlined before. Here, I would kind of expect a
          > standards based approach allowing for the client to determine which kind
          > of representations a server is capable to provide, to by then know
          > "there's text, there's a pdf, and there's a video clip of the same
          > content, too". What is the best way of dealing with such a requirement,
          > both in terms of interoperability and in terms of "clean-ness of design"?
          >
          > - Right now, I make use of Atom <entry>'s and rel="alternate" links to
          > keep such things together. Apart from at least _feeling_ a bit strange
          > (now the different "representations" of the same thing are linked as
          > "alternate" from an Atom <entry> which does not represent but just
          > describe that actual resource) I am left with another question: Right
          > now, with this approach, I easily can provide a client system with the
          > information which media type representations are available for that very
          > resource. However this just (obviously) works whenever accessing the
          > <entry> resource first, to by then see a structure like
          >
          > http://.../documentation/how-to-build-that-table
          >
          > having link rel="alternate" to
          >
          > http://.../documentation/how-to-build-that-table/file.mp4
          > http://.../documentation/how-to-build-that-table/file.pdf
          > http://.../documentation/how-to-build-that-table/file.txt
          >
          > which works. However, in such a situation, to tell which alternate
          > representations are there, I always will have to access the
          >
          > http://.../documentation/how-to-build-that-table
          >
          > resource first, which means that I have to know this one. I so far
          > haven't figured out an obvious, portable way how to, in example starting
          > out with the "application/pdf" representation, tell that there are
          > alternative media type representations available, as well.
          >
          > Hmm. Maybe I am missing something essential / fundamental / trivial
          > about that, or I made a fundamental mistake in thinking about my
          > resource design. Inspirations / thoughts, anyone?
          >
          > TIA and all the best,
          > Kristian
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >

          --
          erik wilde | mailto:dret@...  -  tel:+1-510-2061079 |
                      | UC Berkeley  -  School of Information (ISchool) |
                      | http://dret.net/netdret http://twitter.com/dret |


          ------------------------------------

          Yahoo! Groups Links

          <*> To visit your group on the web, go to:
              http://groups.yahoo.com/group/rest-discuss/

          <*> Your email settings:
              Individual Email | Traditional

          <*> To change settings online go to:
              http://groups.yahoo.com/group/rest-discuss/join
              (Yahoo! ID required)

          <*> To change settings via email:
              rest-discuss-digest@yahoogroups.com
              rest-discuss-fullfeatured@yahoogroups.com

          <*> To unsubscribe from this group, send an email to:
              rest-discuss-unsubscribe@yahoogroups.com

          <*> Your use of Yahoo! Groups is subject to:
              http://docs.yahoo.com/info/terms/


        • Erik Wilde
          all good suggestions, but consider using canonical anyway, so that there is a well-defined identifier for the resource, and not just for all variants.
          Message 4 of 8 , Oct 4, 2012
          • 0 Attachment
            all good suggestions, but consider using canonical anyway, so that there is a well-defined identifier for the resource, and not just for all variants.

            On Oct 4, 2012, at 18:38, mike amundsen <mamund@...> wrote:

            consider:

            1) use link headers with the response that return the list of all other representations for the current response (work on rel values for this)

            2) support for an OPTIONS call for the current URI that return the list of possible reprsentations for the current response

            3) arrange a client-drive negotiation model where the server returns 300 w/ a list of possible representations and the client picks which it wants this time

            each has pros/cons, but none of the options are dependent upon a particular media type or canonical URI as a starting point.

            hope this gives you some ideas.

            mca+1.859.757.1449
            skype: mca.amundsen
            http://amundsen.com/blog/
            http://twitter.com/mamund
            https://github.com/mamund
            http://www.linkedin.com/in/mikeamundsen


            On Thu, Oct 4, 2012 at 8:06 PM, Erik Wilde <dret@...> wrote:
            RFC 6596, maybe? cheers, dret.

            On 2012-10-04 11:28 , Kristian Rink wrote:
            > Folks;
            >
            > trying to build REST resources that make heavy use of delivering
            > different representations of binary files, I ended up looking for
            > thoughts on how to deal with alternate representations of a resource in
            > different media types.
            >
            > To outline the issue in a simple example: Imagine instructions on how to
            > assemble a piece of furniture bought in some large store. These
            > instructions are made available, say, as "text/html" (written
            > description of what to do), "application/pdf" (step-by-step instructions
            > in illustrations) and "application/mp4" (video showing what needs to be
            > done).
            >
            > All the things basically represent the same resource, the same content,
            > in just different representations. There's two things that make me think:
            >
            > - As far as I understood content negotiation by now, this is sort of a
            > client-driven procedure: Client provides a more or less lengthy weighted
            > Accept: header, server delivers the kind of representation content type
            > that seems to suit the client best, based upon Accept:, language, and of
            > course the kind of stuff the server is capable of providing, after all.
            > While this is neat when making client and server quietly make up whether
            > to transfer and render image/gif or image/png, it seems to fall short in
            > a case as the one outlined before. Here, I would kind of expect a
            > standards based approach allowing for the client to determine which kind
            > of representations a server is capable to provide, to by then know
            > "there's text, there's a pdf, and there's a video clip of the same
            > content, too". What is the best way of dealing with such a requirement,
            > both in terms of interoperability and in terms of "clean-ness of design"?
            >
            > - Right now, I make use of Atom <entry>'s and rel="alternate" links to
            > keep such things together. Apart from at least _feeling_ a bit strange
            > (now the different "representations" of the same thing are linked as
            > "alternate" from an Atom <entry> which does not represent but just
            > describe that actual resource) I am left with another question: Right
            > now, with this approach, I easily can provide a client system with the
            > information which media type representations are available for that very
            > resource. However this just (obviously) works whenever accessing the
            > <entry> resource first, to by then see a structure like
            >
            > http://.../documentation/how-to-build-that-table
            >
            > having link rel="alternate" to
            >
            > http://.../documentation/how-to-build-that-table/file.mp4
            > http://.../documentation/how-to-build-that-table/file.pdf
            > http://.../documentation/how-to-build-that-table/file.txt
            >
            > which works. However, in such a situation, to tell which alternate
            > representations are there, I always will have to access the
            >
            > http://.../documentation/how-to-build-that-table
            >
            > resource first, which means that I have to know this one. I so far
            > haven't figured out an obvious, portable way how to, in example starting
            > out with the "application/pdf" representation, tell that there are
            > alternative media type representations available, as well.
            >
            > Hmm. Maybe I am missing something essential / fundamental / trivial
            > about that, or I made a fundamental mistake in thinking about my
            > resource design. Inspirations / thoughts, anyone?
            >
            > TIA and all the best,
            > Kristian
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >

            --
            erik wilde | mailto:dret@...  -  tel:+1-510-2061079 |
                        | UC Berkeley  -  School of Information (ISchool) |
                        | http://dret.net/netdret http://twitter.com/dret |


            ------------------------------------

            Yahoo! Groups Links

            <*> To visit your group on the web, go to:
                http://groups.yahoo.com/group/rest-discuss/

            <*> Your email settings:
                Individual Email | Traditional

            <*> To change settings online go to:
                http://groups.yahoo.com/group/rest-discuss/join
                (Yahoo! ID required)

            <*> To change settings via email:
                rest-discuss-digest@yahoogroups.com
                rest-discuss-fullfeatured@yahoogroups.com

            <*> To unsubscribe from this group, send an email to:
                rest-discuss-unsubscribe@yahoogroups.com

            <*> Your use of Yahoo! Groups is subject to:
                http://docs.yahoo.com/info/terms/


          • mike amundsen
            yep, using canonical is good, esp. in cases where you have multiple representations. my point was to give you a way to get all other options within easy reach.
            Message 5 of 8 , Oct 4, 2012
            • 0 Attachment
              yep, using canonical is good, esp. in cases where you have multiple representations.

              my point was to give you a way to get all other options within easy reach. you can mark one of them canonical, too.

              mca+1.859.757.1449
              skype: mca.amundsen
              http://amundsen.com/blog/
              http://twitter.com/mamund
              https://github.com/mamund
              http://www.linkedin.com/in/mikeamundsen


              On Thu, Oct 4, 2012 at 10:00 PM, Erik Wilde <dret@...> wrote:
              all good suggestions, but consider using canonical anyway, so that there is a well-defined identifier for the resource, and not just for all variants.


              On Oct 4, 2012, at 18:38, mike amundsen <mamund@...> wrote:



              consider:

              1) use link headers with the response that return the list of all other representations for the current response (work on rel values for this)

              2) support for an OPTIONS call for the current URI that return the list of possible reprsentations for the current response

              3) arrange a client-drive negotiation model where the server returns 300 w/ a list of possible representations and the client picks which it wants this time

              each has pros/cons, but none of the options are dependent upon a particular media type or canonical URI as a starting point.

              hope this gives you some ideas.

              mca+1.859.757.1449
              skype: mca.amundsen
              http://amundsen.com/blog/
              http://twitter.com/mamund
              https://github.com/mamund
              http://www.linkedin.com/in/mikeamundsen


              On Thu, Oct 4, 2012 at 8:06 PM, Erik Wilde <dret@...> wrote:
              RFC 6596, maybe? cheers, dret.

              On 2012-10-04 11:28 , Kristian Rink wrote:
              > Folks;
              >
              > trying to build REST resources that make heavy use of delivering
              > different representations of binary files, I ended up looking for
              > thoughts on how to deal with alternate representations of a resource in
              > different media types.
              >
              > To outline the issue in a simple example: Imagine instructions on how to
              > assemble a piece of furniture bought in some large store. These
              > instructions are made available, say, as "text/html" (written
              > description of what to do), "application/pdf" (step-by-step instructions
              > in illustrations) and "application/mp4" (video showing what needs to be
              > done).
              >
              > All the things basically represent the same resource, the same content,
              > in just different representations. There's two things that make me think:
              >
              > - As far as I understood content negotiation by now, this is sort of a
              > client-driven procedure: Client provides a more or less lengthy weighted
              > Accept: header, server delivers the kind of representation content type
              > that seems to suit the client best, based upon Accept:, language, and of
              > course the kind of stuff the server is capable of providing, after all.
              > While this is neat when making client and server quietly make up whether
              > to transfer and render image/gif or image/png, it seems to fall short in
              > a case as the one outlined before. Here, I would kind of expect a
              > standards based approach allowing for the client to determine which kind
              > of representations a server is capable to provide, to by then know
              > "there's text, there's a pdf, and there's a video clip of the same
              > content, too". What is the best way of dealing with such a requirement,
              > both in terms of interoperability and in terms of "clean-ness of design"?
              >
              > - Right now, I make use of Atom <entry>'s and rel="alternate" links to
              > keep such things together. Apart from at least _feeling_ a bit strange
              > (now the different "representations" of the same thing are linked as
              > "alternate" from an Atom <entry> which does not represent but just
              > describe that actual resource) I am left with another question: Right
              > now, with this approach, I easily can provide a client system with the
              > information which media type representations are available for that very
              > resource. However this just (obviously) works whenever accessing the
              > <entry> resource first, to by then see a structure like
              >
              > http://.../documentation/how-to-build-that-table
              >
              > having link rel="alternate" to
              >
              > http://.../documentation/how-to-build-that-table/file.mp4
              > http://.../documentation/how-to-build-that-table/file.pdf
              > http://.../documentation/how-to-build-that-table/file.txt
              >
              > which works. However, in such a situation, to tell which alternate
              > representations are there, I always will have to access the
              >
              > http://.../documentation/how-to-build-that-table
              >
              > resource first, which means that I have to know this one. I so far
              > haven't figured out an obvious, portable way how to, in example starting
              > out with the "application/pdf" representation, tell that there are
              > alternative media type representations available, as well.
              >
              > Hmm. Maybe I am missing something essential / fundamental / trivial
              > about that, or I made a fundamental mistake in thinking about my
              > resource design. Inspirations / thoughts, anyone?
              >
              > TIA and all the best,
              > Kristian
              >
              >
              > ------------------------------------
              >
              > Yahoo! Groups Links
              >
              >
              >

              --
              erik wilde | mailto:dret@...  -  tel:+1-510-2061079 |
                          | UC Berkeley  -  School of Information (ISchool) |
                          | http://dret.net/netdret http://twitter.com/dret |


              ------------------------------------

              Yahoo! Groups Links

              <*> To visit your group on the web, go to:
                  http://groups.yahoo.com/group/rest-discuss/

              <*> Your email settings:
                  Individual Email | Traditional

              <*> To change settings online go to:
                  http://groups.yahoo.com/group/rest-discuss/join
                  (Yahoo! ID required)

              <*> To change settings via email:
                  rest-discuss-digest@yahoogroups.com
                  rest-discuss-fullfeatured@yahoogroups.com

              <*> To unsubscribe from this group, send an email to:
                  rest-discuss-unsubscribe@yahoogroups.com

              <*> Your use of Yahoo! Groups is subject to:
                  http://docs.yahoo.com/info/terms/





            • Jan Algermissen
              ... Alternates: comes to mind: http://jalg.net/2010/09/spotted-alternates-header-in-the-wild/ Jan
              Message 6 of 8 , Oct 5, 2012
              • 0 Attachment
                On Oct 5, 2012, at 4:05 AM, mike amundsen wrote:

                > yep, using canonical is good, esp. in cases where you have multiple representations.

                'Alternates:' comes to mind:

                http://jalg.net/2010/09/spotted-alternates-header-in-the-wild/

                Jan

                >
                >
                > my point was to give you a way to get all other options within easy reach. you can mark one of them canonical, too.
                >
                > mca+1.859.757.1449
                > skype: mca.amundsen
                > http://amundsen.com/blog/
                > http://twitter.com/mamund
                > https://github.com/mamund
                > http://www.linkedin.com/in/mikeamundsen
                >
                >
                > On Thu, Oct 4, 2012 at 10:00 PM, Erik Wilde <dret@...> wrote:
                > all good suggestions, but consider using canonical anyway, so that there is a well-defined identifier for the resource, and not just for all variants.
                >
                >
                > On Oct 4, 2012, at 18:38, mike amundsen <mamund@...> wrote:
                >
                >>
                >>
                >> consider:
                >>
                >> 1) use link headers with the response that return the list of all other representations for the current response (work on rel values for this)
                >>
                >> 2) support for an OPTIONS call for the current URI that return the list of possible reprsentations for the current response
                >>
                >> 3) arrange a client-drive negotiation model where the server returns 300 w/ a list of possible representations and the client picks which it wants this time
                >>
                >> each has pros/cons, but none of the options are dependent upon a particular media type or canonical URI as a starting point.
                >>
                >> hope this gives you some ideas.
                >>
                >> mca+1.859.757.1449
                >> skype: mca.amundsen
                >> http://amundsen.com/blog/
                >> http://twitter.com/mamund
                >> https://github.com/mamund
                >> http://www.linkedin.com/in/mikeamundsen
                >>
                >>
                >> On Thu, Oct 4, 2012 at 8:06 PM, Erik Wilde <dret@...> wrote:
                >> RFC 6596, maybe? cheers, dret.
                >>
                >> On 2012-10-04 11:28 , Kristian Rink wrote:
                >> > Folks;
                >> >
                >> > trying to build REST resources that make heavy use of delivering
                >> > different representations of binary files, I ended up looking for
                >> > thoughts on how to deal with alternate representations of a resource in
                >> > different media types.
                >> >
                >> > To outline the issue in a simple example: Imagine instructions on how to
                >> > assemble a piece of furniture bought in some large store. These
                >> > instructions are made available, say, as "text/html" (written
                >> > description of what to do), "application/pdf" (step-by-step instructions
                >> > in illustrations) and "application/mp4" (video showing what needs to be
                >> > done).
                >> >
                >> > All the things basically represent the same resource, the same content,
                >> > in just different representations. There's two things that make me think:
                >> >
                >> > - As far as I understood content negotiation by now, this is sort of a
                >> > client-driven procedure: Client provides a more or less lengthy weighted
                >> > Accept: header, server delivers the kind of representation content type
                >> > that seems to suit the client best, based upon Accept:, language, and of
                >> > course the kind of stuff the server is capable of providing, after all.
                >> > While this is neat when making client and server quietly make up whether
                >> > to transfer and render image/gif or image/png, it seems to fall short in
                >> > a case as the one outlined before. Here, I would kind of expect a
                >> > standards based approach allowing for the client to determine which kind
                >> > of representations a server is capable to provide, to by then know
                >> > "there's text, there's a pdf, and there's a video clip of the same
                >> > content, too". What is the best way of dealing with such a requirement,
                >> > both in terms of interoperability and in terms of "clean-ness of design"?
                >> >
                >> > - Right now, I make use of Atom <entry>'s and rel="alternate" links to
                >> > keep such things together. Apart from at least _feeling_ a bit strange
                >> > (now the different "representations" of the same thing are linked as
                >> > "alternate" from an Atom <entry> which does not represent but just
                >> > describe that actual resource) I am left with another question: Right
                >> > now, with this approach, I easily can provide a client system with the
                >> > information which media type representations are available for that very
                >> > resource. However this just (obviously) works whenever accessing the
                >> > <entry> resource first, to by then see a structure like
                >> >
                >> > http://.../documentation/how-to-build-that-table
                >> >
                >> > having link rel="alternate" to
                >> >
                >> > http://.../documentation/how-to-build-that-table/file.mp4
                >> > http://.../documentation/how-to-build-that-table/file.pdf
                >> > http://.../documentation/how-to-build-that-table/file.txt
                >> >
                >> > which works. However, in such a situation, to tell which alternate
                >> > representations are there, I always will have to access the
                >> >
                >> > http://.../documentation/how-to-build-that-table
                >> >
                >> > resource first, which means that I have to know this one. I so far
                >> > haven't figured out an obvious, portable way how to, in example starting
                >> > out with the "application/pdf" representation, tell that there are
                >> > alternative media type representations available, as well.
                >> >
                >> > Hmm. Maybe I am missing something essential / fundamental / trivial
                >> > about that, or I made a fundamental mistake in thinking about my
                >> > resource design. Inspirations / thoughts, anyone?
                >> >
                >> > TIA and all the best,
                >> > Kristian
                >> >
                >> >
                >> > ------------------------------------
                >> >
                >> > Yahoo! Groups Links
                >> >
                >> >
                >> >
                >>
                >> --
                >> erik wilde | mailto:dret@... - tel:+1-510-2061079 |
                >> | UC Berkeley - School of Information (ISchool) |
                >> | http://dret.net/netdret http://twitter.com/dret |
                >>
                >>
                >> ------------------------------------
                >>
                >> Yahoo! Groups Links
                >>
                >>
                >>
                >>
                >>
                >>
                >
                >
                >
              • Kristian Rink
                Folks; first off, thanks a bunch for your comments, greatly appreciated. ... Thanks for pointing me there. The approach outlined in there seems definitely
                Message 7 of 8 , Oct 5, 2012
                • 0 Attachment
                  Folks;

                  first off, thanks a bunch for your comments, greatly appreciated.

                  Am 05.10.2012 02:06, schrieb Erik Wilde:
                  > RFC 6596, maybe? cheers, dret.

                  Thanks for pointing me there. The approach outlined in there seems
                  definitely reasonable, and I will definitely take a look in implementing
                  this, eventually based upon header fields to work with binary resources,
                  too. However:



                  Am 05.10.2012 03:38, schrieb mike amundsen:
                  >
                  > 1) use link headers with the response that return the list of all
                  > other representations for the current response (work on rel values
                  > for this)
                  >
                  > 2) support for an OPTIONS call for the current URI that return the
                  > list of possible reprsentations for the current response
                  >
                  > 3) arrange a client-drive negotiation model where the server returns
                  > 300 w/ a list of possible representations and the client picks which
                  > it wants this time

                  So far I thought about (1) and (3) already. Is there any of these
                  options, including RFC 6596, to be preferred from an interoperability
                  point of view, talking about various software systems accessing these
                  resources, including browsers? I.e. it seems people are pretty much
                  reluctant to using / implementing OPTIONS, for whichever reasons.

                  TIA and all the best,
                  Kristian
                • Rushforth, Peter
                  Hi, What about the opposite direction relation? So you are viewing the representation at the canonical URI, and there is a (templated) link to (all) the
                  Message 8 of 8 , Oct 5, 2012
                  • 0 Attachment
                    Hi,

                    What about the opposite direction relation? So you are viewing the representation at the canonical URI, and there is a (templated) link to (all) the alternates. So far I am calling this link@rel="api", but I also thought of "views". "alternates" might also work, but it is as non-standard as the others.

                    Cheers,
                    Peter

                    ________________________________
                    From: rest-discuss@yahoogroups.com [rest-discuss@yahoogroups.com] on behalf of mike amundsen [mamund@...]
                    Sent: October 4, 2012 10:05 PM
                    To: Erik Wilde
                    Cc: REST Discuss; Kristian Rink
                    Subject: Re: [rest-discuss] discovering "alternate" representations?



                    yep, using canonical is good, esp. in cases where you have multiple representations.

                    my point was to give you a way to get all other options within easy reach. you can mark one of them canonical, too.

                    mca+1.859.757.1449
                    skype: mca.amundsen
                    http://amundsen.com/blog/
                    http://twitter.com/mamund
                    https://github.com/mamund
                    http://www.linkedin.com/in/mikeamundsen


                    On Thu, Oct 4, 2012 at 10:00 PM, Erik Wilde <dret@...<mailto:dret@...>> wrote:
                    all good suggestions, but consider using canonical anyway, so that there is a well-defined identifier for the resource, and not just for all variants.


                    On Oct 4, 2012, at 18:38, mike amundsen <mamund@...<mailto:mamund@...>> wrote:



                    consider:

                    1) use link headers with the response that return the list of all other representations for the current response (work on rel values for this)

                    2) support for an OPTIONS call for the current URI that return the list of possible reprsentations for the current response

                    3) arrange a client-drive negotiation model where the server returns 300 w/ a list of possible representations and the client picks which it wants this time

                    each has pros/cons, but none of the options are dependent upon a particular media type or canonical URI as a starting point.

                    hope this gives you some ideas.

                    mca+1.859.757.1449<tel:%2B1.859.757.1449>
                    skype: mca.amundsen
                    http://amundsen.com/blog/
                    http://twitter.com/mamund
                    https://github.com/mamund
                    http://www.linkedin.com/in/mikeamundsen


                    On Thu, Oct 4, 2012 at 8:06 PM, Erik Wilde <dret@...<mailto:dret@...>> wrote:
                    RFC 6596, maybe? cheers, dret.

                    On 2012-10-04 11:28 , Kristian Rink wrote:
                    > Folks;
                    >
                    > trying to build REST resources that make heavy use of delivering
                    > different representations of binary files, I ended up looking for
                    > thoughts on how to deal with alternate representations of a resource in
                    > different media types.
                    >
                    > To outline the issue in a simple example: Imagine instructions on how to
                    > assemble a piece of furniture bought in some large store. These
                    > instructions are made available, say, as "text/html" (written
                    > description of what to do), "application/pdf" (step-by-step instructions
                    > in illustrations) and "application/mp4" (video showing what needs to be
                    > done).
                    >
                    > All the things basically represent the same resource, the same content,
                    > in just different representations. There's two things that make me think:
                    >
                    > - As far as I understood content negotiation by now, this is sort of a
                    > client-driven procedure: Client provides a more or less lengthy weighted
                    > Accept: header, server delivers the kind of representation content type
                    > that seems to suit the client best, based upon Accept:, language, and of
                    > course the kind of stuff the server is capable of providing, after all.
                    > While this is neat when making client and server quietly make up whether
                    > to transfer and render image/gif or image/png, it seems to fall short in
                    > a case as the one outlined before. Here, I would kind of expect a
                    > standards based approach allowing for the client to determine which kind
                    > of representations a server is capable to provide, to by then know
                    > "there's text, there's a pdf, and there's a video clip of the same
                    > content, too". What is the best way of dealing with such a requirement,
                    > both in terms of interoperability and in terms of "clean-ness of design"?
                    >
                    > - Right now, I make use of Atom <entry>'s and rel="alternate" links to
                    > keep such things together. Apart from at least _feeling_ a bit strange
                    > (now the different "representations" of the same thing are linked as
                    > "alternate" from an Atom <entry> which does not represent but just
                    > describe that actual resource) I am left with another question: Right
                    > now, with this approach, I easily can provide a client system with the
                    > information which media type representations are available for that very
                    > resource. However this just (obviously) works whenever accessing the
                    > <entry> resource first, to by then see a structure like
                    >
                    > http://.../documentation/how-to-build-that-table<UrlBlockedError.aspx>
                    >
                    > having link rel="alternate" to
                    >
                    > http://.../documentation/how-to-build-that-table/file.mp4<UrlBlockedError.aspx>
                    > http://.../documentation/how-to-build-that-table/file.pdf<UrlBlockedError.aspx>
                    > http://.../documentation/how-to-build-that-table/file.txt<UrlBlockedError.aspx>
                    >
                    > which works. However, in such a situation, to tell which alternate
                    > representations are there, I always will have to access the
                    >
                    > http://.../documentation/how-to-build-that-table<UrlBlockedError.aspx>
                    >
                    > resource first, which means that I have to know this one. I so far
                    > haven't figured out an obvious, portable way how to, in example starting
                    > out with the "application/pdf" representation, tell that there are
                    > alternative media type representations available, as well.
                    >
                    > Hmm. Maybe I am missing something essential / fundamental / trivial
                    > about that, or I made a fundamental mistake in thinking about my
                    > resource design. Inspirations / thoughts, anyone?
                    >
                    > TIA and all the best,
                    > Kristian
                    >
                    >
                    > ------------------------------------
                    >
                    > Yahoo! Groups Links
                    >
                    >
                    >

                    --
                    erik wilde | mailto:dret@...<mailto:dret@...> - tel:+1-510-2061079<tel:%2B1-510-2061079> |
                    | UC Berkeley - School of Information (ISchool) |
                    | http://dret.net/netdret http://twitter.com/dret |


                    ------------------------------------

                    Yahoo! Groups Links
                  Your message has been successfully submitted and would be delivered to recipients shortly.