Hi guys,

I'm currently developing an HTTP interface (can't dare to call it
REST) for a few clients and I have a question for y'all.

I have a resource, /video/{id}, which contains metadata of a video (in
Atom) with a few outgoing links to different formats of the original
source file (let's say that I take, in input, an AVI, and produce
mpeg, ogv and so on).

I tried to represent the link to video files with:
https://gist.github.com/1352232

but I really don't know if the "alternate" link semantic is the right
one. Anyone has suggestions?

--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

On Nov 9, 2011, at 6:46 PM, Alessandro Nadalin wrote:

> Hi guys,
>
> I'm currently developing an HTTP interface (can't dare to call it
> REST) for a few clients and I have a question for y'all.
>
> I have a resource, /video/{id}, which contains metadata of a video (in
> Atom) with a few outgoing links to different formats of the original
> source file (let's say that I take, in input, an AVI, and produce
> mpeg, ogv and so on).
>
> I tried to represent the link to video files with:
> https://gist.github.com/1352232
>
> but I really don't know if the "alternate" link semantic is the right
> one. Anyone has suggestions?

I think that makes sense. Personally, I am not a friend of the type parameter (I
prefer to let content negotiation handle the selection), but for your use case
it seems like a good option.

You might want to look at NewsML 2 one day for inspiration. IIRC it has quite
sophisticated meta data for media.
(But it is a huge, sort of complicated spec and format).

http://www.iptc.org/site/News_Exchange_Formats/NewsML-G2/

Jan



>
> --
> Nadalin Alessandro
> www.odino.org
> www.twitter.com/_odino_
>

On Wed, Nov 9, 2011 at 6:56 PM, Jan Algermissen
<jan.algermissen@...> wrote:
>>
>> but I really don't know if the "alternate" link semantic is the right
>> one. Anyone has suggestions?
>
> I think that makes sense. Personally, I am not a friend of the type parameter
(I prefer to let content negotiation handle the selection), but for your use
case it seems like a good option.
>

Uh jan, good point, I forgot to think about negotiation, since I'm
used to it with "canonical" types (json/atom/xhtml...)

@erik: just wondering :)

>
> Jan
>
>
>
>>
>> --
>> Nadalin Alessandro
>> www.odino.org
>> www.twitter.com/_odino_
>>
>
>



--
Nadalin Alessandro
www.odino.org
www.twitter.com/_odino_

hello.

On 2011-11-09 10:16 , Alessandro Nadalin wrote:
> On Wed, Nov 9, 2011 at 6:56 PM, Jan Algermissen
> <jan.algermissen@...>  wrote:
>>> but I really don't know if the "alternate" link semantic is the right
>>> one. Anyone has suggestions?
>> I think that makes sense. Personally, I am not a friend of the type parameter
(I prefer to let content negotiation handle the selection), but for your use
case it seems like a good option.
> Uh jan, good point, I forgot to think about negotiation, since I'm
> used to it with "canonical" types (json/atom/xhtml...)
> @erik: just wondering :)

agreeing with eric here: it's nice to have server-driven content
negotiation and have "gateway resources" supporting it, but it's also
nice to have stable and exposed URIs for specific renditions, and as
long as everything is correctly labeled and interlinked, it's nicely
RESTful and allows clients some choice.

cheers,

dret.

Jan Algermissen wrote:
>
> I think that makes sense. Personally, I am not a friend of the type
> parameter (I prefer to let content negotiation handle the selection),
> but for your use case it seems like a good option.
>

Upon receiving this representation, the user-agent knows the shared URI
it can use for server-driven negotiation; and is also informed of the
number, nature and location of variants in order to perform client-
driven negotiation (to recover from failure, etc.).  I don't see how
@type is ever a bad thing (unless it's wrong) -- if a user-agent only
knows one of the available types, why incur the added latency of conneg
on each request?  While conneg is a great general-purpose tool for
general-purpose clients, it gets in the way of purpose-built clients
getting their work done, so it would be a shame if no @type existed to
inform purpose-built clients how to bypass conneg.

-Eric

Alessandro Nadalin wrote:
>
> but I really don't know if the "alternate" link semantic is the right
> one. Anyone has suggestions?
>

Why not?  Looks like long-standing best-practice to me.

-Eric