Subject: link/@type and content negotiation

From: Erik Wilde <[email-masked]>
Date: Fri, 04 Sep 2009 15:44:38 -0700

hello.

in the context of some work we're doing that is attempting to describe 
RESTful services, one important problem is how to deal with media types. 
for HTTP URIs, servers can return various media types and this may 
happen via HTTP content negotiation. Atom's link/@type links to a URI 
and specifies a media type, but this mechanism supports only one type 
that can be specified. does anybody have any opinion or experience or 
best practice what to do in scenarios where that URI is actually 
supporting content negotiation?

thanks and kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        [email-masked]  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

---

From: Peter Keane <[email-masked]>
Date: Fri, 4 Sep 2009 21:52:38 -0500

Erik-

I'm not sure if this address the question exactly, but you might look at:

http://www.imc.org/atom-syntax/mail-archive/msg01891.html

In our system (like Sam Ruby's message says), we typically have multiple
links w/ same URL & @rel but each has a different media-type:

<link href="http://example.com/some-resource"  rel="
http://example.com/relation/edit-json" type="application/json"/>
<link href="http://example.com/some-resource"  rel="edit"
type="application/atom+xml"/>

(well, in practice we had trouble w/ conneg so we also attach an extension
on the URL, but in theory that's not needed)

I know there was a thread somewhere (here or rest-discuss ??) about using
@type to hold, essentially, an accept header, but there were lots of (good,
I think) arguments about why that was not a good idea.  I'll pass along if I
find it.

--peter

On Fri, Sep 4, 2009 at 5:44 PM, Erik Wilde <[email-masked]> wrote:

> RESTful services, one important problem is how to deal with media types. for
> HTTP URIs, servers can return various media types and this may happen via
> HTTP content negotiation. Atom's link/@type links to a URI and specifies a
> media type, but this mechanism supports only one type that can be specified.
> does anybody have any opinion or experience or best practice what to do in
> scenarios where that URI is actually supporting content negotiation?
>
> thanks and kind regards,
>

---

From: Erik Wilde <[email-masked]>
Date: Mon, 07 Sep 2009 15:20:03 -0700

hello peter.

> <link href="http://example.com/some-resource" rel="http://example.com/relation/edit-json" type="application/json"/>
> <link href="http://example.com/some-resource" rel="edit" type="application/atom+xml"/>

that's probably the most obvious way of doing it (assuming you wanted to 
show something here that actually had identical @type values ;-), but it 
kind of denormalizes the actual information about just one resource 
being linked. it could be "re-normalized" if clients expected this kind 
of pattern and would conclude that this has to be a conneg resource. if 
conneg was more widely used, it might actually be supported in a 
language itself, but it seems that Atom decided that there was no need 
to have special support for this use case.

thanks and cheers,