Re: discovering "alternate" representations?

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 <[email protected]> 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 <[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
>> 
>> 
>> 
> 
> 
> 
>