Its a rare day that a truly good standard comes along. Its an even rarer day that the standard get widely adopted. So the developers of Atom should stand up and take a bow – not only did they hit a home run with the Atom syndication format, they’ve done it again with the Atom publishing protocol. In case you are not familiar with Atom, the syndication format provides a standard format for saving blog content in XML and the publishing protocol provides a standard API for clients to read, create or update Atom documents stored on servers.

Its certainly not news that the Atom syndication format is both technically and socially a better blogging format than myriad flavors of RSS. Nor is it news that the Atom publishing protocol is more capable replacement than what proceeded it.

What is news is the surprisingly deep and capable technology platform Atom offers, making it suitable for a large range of applications well beyond blogging software. In fact I believe we’re witnessing the birth of the next great technology standard, with Atom taking its place alongside HTML, HTTP and the underlying protocols that support the Internet.

Emergent Properties

Atom is so useful because of the emergent properties that arise from its unique combination of:

• A simple data model of collections that contain entries
• Careful selection of the most important metadata (author, update time, etc.)
• Support of attached pictures, songs and video to entries
• Extensibility through XML namespaces
• A standard REST API that fully leverages HTTP
• Easy to read, short specifications that can be implemented in a good days worth of hacking

Starting with the data model, it turns out that modeling the world as collections that contain entries is awfully useful. Clearly this model works well for blogs, which are a collection of articles. But it also works across a vast range of domains, such as modeling records in tables, songs in collections, features on a map, items in a shopping cart, books in a library, etc. Then for each entry, Atom defines a small set of the most useful attributes, such as name, published date, etc (these attributes mostly overlap with the Dublin Core attributes). It also lets you easily associate different types of media with each entry – a song, a picture, a podcast, a location, etc.

Therefore right off the bat Atom provides a universal way that computers can share a base level of information about whatever things they model. Atom then takes this a step farther by allowing custom information to be embedded via the use of XML namespaces. Thus you can use XHTML to embed a story, GeoRSS to embed coordinate information, rank extensions to embed rating information, threading extensions to embed comments, etc.

Providing a common format that many different computer systems can understand is just the first part of the problem though. The second part is how can the computer systems talk to each other to actually exchange information? This is where the Atom publishing protocol shines.

As opposed to inventing yet another RPC (remote procedure call) API, it deftly leverages HTTP by simply sticking to its defined verbs such as GET, POST, PUT and DELETE. To those in the know, this type of API is called a REST API, which I’ve written about previously here, here and here if you’re interested. Unfortunately, REST is not as clear cut as it could be as witnessed by never debates about various arcane technical details (PUT versus POST for example). The Atom publishing protocol dispenses of these problems by simply defining explicitly how client and servers should interact.

Finally, both the Atom syndication format and publishing protocol are simple to implement since they build off the strong foundation of provided by XML and HTTP. For the work I’ve done with MapBuzz, I had an Atom feed up in running in a couple hours and full support for the Atom publishing protocol in a day.

One Format to Rule Them All

By combining a simple data model, a standard data exchange format, easy extensibility and a common API and simple specifications, Atom offers a great foundation for building web services. Its a no-brainer to see that Atom will blow away the WS-DeathStar (which is a mocking tribute to the mountains of specifications that IBM, Microsoft and others have generated for defining web services).

But I think Atom will go farther – it will become the lingua franca of Web Services just as HTML is the lingua franca of the Web. One of the hidden secrets of web services is that exchanging xml documents between computers doesn’t result in integration.  Integration requires every system to understand the same formats – and that takes good old programming by some person. As a result, its become clear over the last few years that inventing a new XML format for every problem domain is not a particularly good idea.

Atom steps into this void – it provides a foundation on which anyone can build. Its much easier to build a Web service by adding some custom content to an Atom feed than it is to create a new XML exchange format and API from scratch. Thus, I believe Atom will become the de facto way of building web services. The first place to look is to Web 2.0 sites. Many currently expose their data via proprietary web service APIs – I’ll wager over the coming year most will move to Atom.

Network Effects

Last, the power of network effects is already working its magic in the Atom world. As Atom becomes more popular, Atom tools get better, making it easier to work with, attracting more users, etc. Atom support has even made it into the latest release of the major browsers. It sure was a nice surprise to find out I could point my browser at a new Atom based web service and it just works – the results are nicely formatted and easy to read – making debugging quick and easy.