When to Use Atom

January 19th, 2010  |  Published in REST by Ian Robinson  |  1 Comment

There are two extremes of Atom usage: everything’s an Atom extension (direct extension) versus everything goes in the atom:content element (enveloping).

A little while ago, Bill de h├ôra expressed his preference for direct extension over enveloping. At its worst, enveloping results in near anaemic Atom entries, with very few of the Atom metadata elements put to good use, rightly prompting Bill’s question: “why bother using Atom at all?”

Like Bill, I’ve gone back and forth between these two options. At present, I’m inclined to use enveloping more than direct extension, but only if I can still put the Atom metadata to good use. If I find I’m having to fill out Atom metadata elements with lots of dummy information, just so that I can use Atom to transfer some opaque data between applications, I quickly turn to another format.

To my mind, Atom’s “meta-purpose” is to establish a domain processing context for some content. In AtomPub, Atom artefacts establish a publishing context for Web content. When used to establish this publishing context, the Atom artefacts are called collections and members, rather than feeds and entries.

I prefer not to extend Atom beyond the domain processing context I’m trying to model: instead, I push the thing to be processed down into the content. This allows for media type composition, whereby one media type processor hands off to another as it works its way through a representation. A reasonably “generic” Atom client can resurrect the domain processing context, which then remains in force whilst a specialized media type handler deals with the content (according to its media type).

In the past I’ve illustrated this point by showing how Atom feeds can be used to represent streams of events. The event metadata maps nicely to Atom metadata. The content itself contains a snapshot of some other resource’s state at the point the event occurred. In other words, the Atom metadata establishes an event-ish processing context for the content. When the client invokes a specialised handler for the content, it does so in the knowledge that its dealing with a representation of state at a particular point of time.

If I can’t separate a given problem into 1) an activity and accompanying processing context (e.g. “eventing”, “publishing”), and 2) the thing to be acted on, I’ll consider using something other than Atom.

1 Comment  |  Atom   RSS 2.0   Email

Responses

  1. Andrew Wahbe says:

    January 20th, 2010 at 4:20 am (#)

    Agreed! I thought I was the only person in the “envelope camp”! (Though I hate the name “envelope” as it has negative connotations for most folks…)

    I think a key point to stress is that this model decouples the processing context and the content. This applies to the data as the content can have its own format and media type (and even it’s own URI) that are independent of Atom. And it also applies to the processors as the generic Atom client could be used with other content types and the content processor could potentially be used in other processing contexts.

    An analogous browser-based application might be an HTML-based employee listing that allows you to download vCards that are handled by a mail client.