Building Apps with RSS, Atom, and the Atom API
Writing about web page http://conferences.oreillynet.com/cs/et2005/view/e_sess/6244
Ben Hammersley (sporting his UtiliKilt)
- RSS / RDF / Atom are syndication formats. RSS has lots of different formats, largely due to it's politicized development process
- Atom: is currently only at v 0.5; is changing quite fast.
- Atom mandates a lot more stuff than RSS
- RSS 2.0 great for machine readable lists. RSS1 good for super-complex interlinked document mining. Atom learns from the experience of RSS1 & 2 and sits somewhere between them.
- [ a diversion about the philosophical origins of the word 'atom' ensues …]
- 5 atomic facts about a document: who (created it), when (it was created), where (it is) , what (it's called), what (it contains). An atom document must state those 5 facts about a document, because if you don't capture that up front you can never get it back with certainty. note to self: how does atom deal with modifications?
- Key concept: Resource - the document + all the data about it. Representation – some view (e.g. html) of the document in an application.
- 2 types of document: an entry and a feed. An entry is the resource in XML - the content and all the metadata.
- Constructs – extension points in the atom schema. 6 types: text, person, date, link, category, identity, service. Ben asserts that these 6 are sufficient.
- I wonder what we could do with an atom entry for every sitebuilder page? It would be a simple alternate rendition
- Ben Hammersley fancies himself to be the Wittgenstein of web syndication ( © John Dale 2005 :-)) Where are his bees?
- Feeds - a collection of documents (entries) plus it's own metadata. A feed is a query over resources. note to self: support for projections?
- Feeds of Feeds are supported, since a feed is also a resource. (an entry can describe a feed)
- History: BloggerAPI, Metaweblog API (XML-RPC / SOAP)
- Atom uses REST
- [ a brief interlude about REST ] Ben's interpretation of PUT/POST is not what I understood: He interprets POST=create, PUT=replace; I would have said PUT=create, POST=update. Must investigate (doubtless I am wrong!)
- note to self: could we define individual warwickgroups as atom entries?
- An atom API call is an atom entry document sent over HTTP with the appropriate verb (method)
- atom endpoints: 4 per system; postURI (one per system), editURI (one per resource), FeedURI (one per query), ResourcePostURI (one per system)
- Adding a link rel="service.post" element to a page makes the PostURI discoverable by atom API-aware clients. similarly for service.edit (edit an entry), service.feed (get feed) etc.
- Features: inherits from lower-level protocols e.g. internationalisation (use XML) authentication, cacheing (use HTTP), encryption (use SSL). Keeps the spec small; means clients must be multi-protocol aware.
- Versions: Each version is its own resource (or you could create each diff as it's own resource), and you use a link element with an app-specific tag to indicate that each resource in a version history is related to the same 'document'.
- Documentcentrism – input—>content stored as atom entries—>view
- inputs: atom api, file creation, other interfaces ; output: html, XML, RSS …
- Ben demos his simplest-possible atom CMS, which does HTML and RSS representations of queries over atom resources. In use at the Guardian/Observer, for building their media blog.
- Using apache + http content negotiation is a neat way of having 1 URI serve multiple different renditions of content.
- Atom doesn't specify how to do locking of resources – defers to the application. Not obvious to me how you would communicate to the server that you wished to lock a resource, though it's easy enough to communicate back a lock failure (HTTP 503 resource unavailable or something). Maybe you could represent locks as entries in their own right?