RE: [rest-discuss] discovering "alternate" representations?
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.
From: email@example.com [firstname.lastname@example.org] 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.
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:
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.
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:
> 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
> 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
> having link rel="alternate" to
> which works. However, in such a situation, to tell which alternate
> representations are there, I always will have to access the
> 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,
> 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