Atom Powered Content

The Atom Publishing Protocol could be the biggest thing to hit you in programming that you never heard of. If you do a search for Atom Publishing Protocol or AtomPub as it is also known, you will only get obscure references to technical issues, discussions and description around AtomPub. I was surprised that many analysts and editors of significant technical publications and journals have never heard of either Atom or REST. However, AtomPub is the embodiment of the principles of REST-based programming on the web and is likely to have some of the most significant impact how we program the web going forward.

Atom started when Sam Ruby from IBM sought to define what makes a blog entry and what is a conceptual data model necessary to model a well formed blog entry. After creating a wiki to develop this idea, eventually a collection of people started an IETF working group with Sam as the secretary. Sam had previously been active in Apache and is vice president of the Apache Software Foundation.  Tim Bray, one of the co-editors of XML and now at Sun, co-chaired the Atom Working Group along with Paul Hoffman. This group ended up working on two aspects of the protocol. The first was the Atom subscription format, which you may have seen in conjunction with RSS feeds. This is not surprising since much of the motivation for creating Atom was the divergence and inconsistency of the RSS format. The other side of any subscription protocol is publishing and so the Atom Publishing Protocol specification was born edited by Joe Gregorio, who now works for Google, and Bill de hOra.

Sam Ruby of IBM

The concepts behind AtomPub are simple and powerful. AtomPub is designed to publish and edit web resources. Since everything is accessible from the Web, eventually this means everything. It uses HTTP and the basic operations of the web: GET, POST, PUT and DELETE. What is retrieved and posted are simple concepts of Collections, Categories and Resources organized by Workspaces described by a simple, extensible XML schema. Descriptive information is stored in Service Documents, which describe what Collections are available, and Category Documents, which contain lists of categories available in a workspace. Most data, information and content operations map very nicely into these concepts. AtomPub has quickly moved from its original intention of managing blogs to managing all sorts of information on the internet.

It's significant that the brains behind this standard work at Google, IBM and Sun. Their effects on the standard are becoming pervasive and endemic in Web 2.0. They are defining how REST is being used on the Internet. Google has used AtomPub in the creation of its GData or Google protocols as Joe Gregorio tells us. GData is expanding its use in everything from Google Docs to Google Apps and Google Maps. IBM uses AtomPub in providing mashable interfaces to Lotus Notes and is expanding it use elsewhere as they develop REST-based tools like QEDWiki and Lotus Connections. Sun has been slowly moving Java in the direction of REST and AtomPub, although there is still a lot of work to do there. OpenSearch also supports Atom. In fact, even Microsoft has been developing AtomPub as part of their Microsoft Live Platform after trying to dismiss it with their Web3s protocol.

I credit Rich Howarth at IBM for making me aware of the significance that both REST and Atom will have on the content management industry. During an IECM content management standards meeting hosted by IBM in Boulder in Spring 2006, Rich put forward his views on REST and Atom. Dave Caruana had already been looking at REST that ultimately help create the Alfresco Web Script architecture as well as our OpenSearch interface. However, during debates of Web Services vs. REST, Rich's initial belief and then strong opinion that Atom would become significant helped sway us. Rich was also probably helped by the fact that Sam Ruby works for IBM. My initial reaction was that Atom may be okay for subscriptions like RSS, but how can that help in content management. After discussing this over several meetings, it became clearer that Atom Publishing actually aligns itself quite nicely to content management - content is a resource that streams well using HTTP and is organized into collections - normally folders. In addition, mash-ups are becoming the more common way of integrating information, particularly content, on the web and Atom lends itself nicely to mash-ups due to the REST nature of the protocol.

Boulder in Spring. Brrrr.

We are busily working on an Atom Publishing Protocol for our 3.0 release over the last several months, although it won't be available in the initial release at the end of July. David Caruana and Andy Hind have been heads down working on AtomPub APIs and new query languages based upon the JSR-283 SQL. This will become a very easy way to build scriptable, REST-oriented applications that integrate well with AJAX components and our other REST-based Web Scripts. The now year-old Web Scripts infrastructure has been instrumental in our ability to create a complete, robust and scalable AtomPub set of content services.  We hope to get this out before the end of Summer. We don't expect SOAP and WS-* standards to go away and we will continue to invest in them, but REST and AtomPub will continue to make significant in roads into the market, the web and increasingly content management.