Re: discovering "alternate" representations?

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:[email protected]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |