Atom Content Negotiation

media types are an important part of web architecture, and they even have (some) structure; the very obvious type/subtype syntax, and the maybe not as obvious "+" convention in types such as application/atom+xml. however, while that allows you to expose the fact that something is Atom and that Atom is based on XML, it does not allow you to talk about what the published entries are.

let's assume you have a collection of items that is exposed via feeds and managed in whatever back-end storage works well for you. you want to be a good web citizen and publish it as HTML, XML, JSON, and RDF. you also want to be a good web service citizen and publish any updates via feeds, so that consumers are notified whenever the collection changes. what is the best web pattern to do that? currently, there are two main approaches:

• publish different feeds. in this case, each content type is published in a different feed. one problem is that these feeds are not interlinked, so it is not possible to switch feeds easily. another problem is that there is no way how to advertise these feeds in a way that marks them as being content type variants of the same content.
• link content variants. in our suggestions for Web Services for Recovery.gov, we had just one feed that would embed reports in HTML, and an XML version would be linked in each entry as an alternate version. this clearly makes HTML primary and XML secondary, and if all you're interested in is XML, it forces you to GET all HTML, only to ignore it and then GET the XML.

both approaches have advantages and disadvantages, and both are not very pretty. in addition, when adding more advanced feed-based services such as updates and push, well-defined handling of content types across the whole landscape becomes more important.

i am wondering what the more popular approach is, and why. i am also wondering whether it might be worth the effort to have a small extension that would make this more reliable in the sense that there would be a link relation for interlinking feeds that carry the same content, but using different content types. it could be as simple as having such a link on the feed level:

<link rel="alternate-content" href="..." content-type="application/xml"/>

is that something that would be worth doing? it could become more sophisticated (and complicated) by allowing other feed parameters to be negotiated, such as feed formats (here's an RSS version of me), feed variants (here is the feed with breaking news only, here's the feed with abstracts only), and probably a variety of other things. currently, i would be tempted to do the simple version only, but i am really curious to find out in which cases these problems already have been solved, in which way they have been solved, and whether standardizing this might provide some value.

[[ a pointer to this entry has been posted to the atom-syntax mailing list. ]]

Comments

[Jan Algermissen]

Hi Erik,

(1) do not media type negotiation is a runtime issue and should not be baked into representations because then you'll need to update the implementations of resources when more or less representations are available for other resources. Even worse, other's might point to your application/foo version which makes it hard to stop providing that media type without breaking those pointers.

(2) Hints on the subjects of feeds can already be expressed using Atom categories in service documents.

My 2 cents :-)

Jan

[Jodischneider]

I think marking feed variants is a great idea!

[dret]

@jan, thanks for your comment, but i cannot quite follow your argument. i agree that content type negotiation ideally should be a runtime issue, but how do you do it, then? it seems that the basic feed model of wrapping content in feed formats makes standard HTTP content type negotiation a bit useless, because you're negotiating the feed type, not the actual feed/entry type. so how can we expose the interesting information, the feed/entry content type, to runtime content type negotiation? i don't see your comment addressing the "how", only that it should be done. my original post was exactly about the "how", so what do you think, how should it be done?

[Ekansa]

This would be really useful. I think it could greatly save on the number of requests clients need to make to get data in the desired representations.

Although, I should say that it would be really nice if good Web citizenship was more widespread so that more people published data in multiple representations in the first place.