Re: discovering "alternate" representations?

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