The Atom Publishing Protocol is a failure. Now that I've met by blogging-hyperbole-quotient for the day let's talk about standards, protocols, and technology.
This is all the fodder I was going to throw together for a presentation I proposed for OSCon. Since that proposal got rejected I'm going to post it here. On the other hand, my App Engine tutorial got accepted, so I'll still see you at the conference.
So AtomPub isn't a failure, but it hasn't seen the level of adoption I had hoped to see at this point in its life. There are still plenty of new protocols being developed on a seemingly daily basis, many of which could have used AtomPub, but don't. Also, there is a large amount of AtomPub being adopted in other areas, but that doesn't seem to be getting that much press, ala, I don't see any Atom-Powered Logo on my phones like Tim Bray suggested.
So why hasn't AtomPub stormed the world to become the one true protocol? Well, there are three answers:
I am so looking for an excuse to fly from NYC to SFO so I can use the in-air wifi on Virgin America, but I digress.
Thick clients, RIAs, were supposed to be a much larger component of your online life. The cliche at the time was, "you can't run Word in a browser". Well, we know how well that's held up. I expect a similar lifetime for today's equivalent cliche, "you can't do photo editing in a browser". The reality is that more and more functionality is moving into the browser and that takes away one of the driving forces for an editing protocol.
Another motivation was the "Editing on the airplane" scenario. The idea was that you wouldn't always be online and when you were offline you couldn't use your browser. The part of this cliche that wasn't put down by Virgin Atlantic and Edge cards was finished off by Gears and DVCS's.
I'm seeing a rise in DVCS based blogging platforms, could that trend extend beyond the highly technical crowd, could 'hg push' be the next big thing in publishing protocols? I digress again.
All of the advances in browsers and connectivity have conspired to keep AtomPub from reaching the widespread adoption that I had envisioned when work started on the protocol, but that doesn't mean it's a failure. There is still plenty of uses for AtomPub and it has quietly appeared in many places. Other use cases are still holding up over time, such as migrating data from one platform to another. Probably the biggest supplier of AtomPub based services is Google with the Google Data APIs, but it also has support from other services; just recently I noticed that flickr offers AtomPub as a method to post images to your blog. So it's not a failure, but certainly the advancing browser platform has obviated many of the motivations behind its creation.
Microsoft is migrating all of its Live Services APIs into a single unified AtomPub API in the Live Framework. It appears they will also open up the ability for third parties to do the same.
I don't think the JSON argument is such a big deal. Google Data APIs support output in JSON and RSS formats. Microsoft's Live Framework supports full CRUD with JSON, AtomPub, and POX, as well as output in RSS. Under the hood, they are simply offering a JSON encoding of AtomPub.
Arguing that browsers are becoming good enough for most app scenarios reminds me of when Steve Jobs initially said that their SDK solution was web apps only. Look how well that turned out compared to what happened when they released a real SDK. Rich apps are here to stay, powered of course by services such as AtomPub.
Posted by Oran on 2009-04-18
Great post -- excellent food for thought. I am especially intrigued/excited about what DVCS's offer for publishing. JSON, HTML, etc. offer great opportunities as well. Atom/AtomPub enthusiasts (like me) need to fight the urge to discount those trends. What I do really like about Atom is the constrained/minimalist data model that it offers. I honestly think that much of the promise of the Semantic Web/RDF will in fact be realized (already is in many ways) by Atom's simpler, tree-based structures (offering graph semantics a tree-at-a-time).
And what AtomPub offers that is so important is a clear example & implementation of RESTful design. Having just completed a project for interop between a Java-based Course Management System (Blackboard) and a home-grown PHP AtomPub enabled asset store, I've seen first hand the power of a really good spec & roadmap for interaction design -- the abstraction was remarkably non-leaky.
I think RESTful JSON implementations ought to look closely at what AtomPub offers. While browsers are shockingly bad at processing XML, they are really good at creating XML out of JSON. Browser-based AtomPub means JSON in the browser and convert-to-Atom before POST/PUT to the server. I'd like to start seeing link[@rel=edit]/@type='application/atom+json' in feeds. I've found that to be a useful pattern for browser based AtomPub (I realize that mime type doesn't exist, but we can hope...).
Posted by pkeane on 2009-04-18
Yet, I am still waiting for the service documents of those Google services. Where are they? To me Atom and AtomPub haven't lost because they are XML and expect full support of HTTP, but purely because large services out there like Facebook, Twitter, Last.fm or MySpace do not want to expose their data in a way that make it easy to aggregate and compute from them. If Wikipedia was even able to use Atom properly, the data exposed would properly reuse category, link and the like i.e. web semantics.
Posted by Sylvain Hellegouarch on 2009-04-18
Posted by kl on 2009-04-18
Posted by alexander on 2009-04-18
Could you expand on this? How does HTML5 remove the need for XML-based document formats? Is your point that HTML5 removes the need for XHTML or you saying something more than that?
Posted by James Clark on 2009-04-18
To me Atom and AtomPub haven't lost because they are XML and expect full support of HTTP, but purely because large services out there like Facebook, Twitter, Last.fm or MySpace do not want to expose their data in a way that make it easy to aggregate and compute from them.I can't imagine anything further from the truth. Twitter has an extensive set of APIs at http://apiwiki.twitter.com and Facebook at http://wiki.developers.facebook.com/index.php/API that go MUCH further than the simple microcontent editing scenarios originally envisioned by AtomPub.
As Joe points out in his post, these services could have built their API sets by starting from AtomPub but they didn't. That is the key indictment of AtomPub that [to me] is the final nail in its coffin and JSON was the hand that held the gun.
PS: Even MySpace has extensive APIs at http://developer.myspace.com/community/ which have AtomPub as option but it is clear that the API (OpenSocial) is JSON-centric and AtomPub support is more for "checklist satisfaction" as opposed to being well supported.
Posted by Dare Obasanjo on 2009-04-19
I'll point to Mark's work in Dive Into Python 3 as an example of what I am talking about.Oran
I don't think the JSON argument is such a big deal. Google Data APIs support output in JSON and RSS formats. Microsoft's Live Framework supports full CRUD with JSON, AtomPub, and POX, as well as output in RSS.
How does that not support my point?
Posted by Joe on 2009-04-19
Posted by Chris Dent on 2009-04-19
As Joe points out in his post, these services could have built their API sets by starting from AtomPub but they didn't. That is the key indictment of AtomPub that [to me] is the final nail in its coffin and JSON was the hand that held the gun.I'm sorry, what? So it can only be a technical issue that prevented those services from using AtomPub. Not a political (or even lack of understanding of the protocol from those services designers, hint Web3S) issue?
I keep thinking that, at an age where the size of your user base as well as the amount of data you have is a premium, providing Atom support in a way that truly supports some of the web semantics promises, companies are really careful not to open up the pipes too loosely and that there are constraints far beyond technical issues explaining why Atom/AtomPub aren't everywhere.
Posted by Sylvain Hellegouarch on 2009-04-19
How does that not support my point?
I don't think AtomPub needs to be reinvented each time some hot new encoding (JSON, M, etc.) comes along, although I can see the temptation to use that as an excuse to "get it right this time."
One of the beauties of REST is that it makes a distinction between a resource and the resource's representation. To me at least, this means there is less of a need for one encoding to "win" at the expense of others. The important (and hard) part is to fully realize the potential of REST, and this is where AtomPub shines as a standardized method for doing REST right.
I think of AtomPub similarly to the abstract XML Infoset. As evidenced by Google Data and especially by Microsoft's Live Framework, Atom is just one possible encoding of AtomPub, with JSON and "POX" being equally valid encodings. To me, this usage of JSON makes AtomPub even more relevant, not less.
Posted by Oran on 2009-04-19
So, in brief: I implemented a massively elegant Atompub middleware for a project and our partners then asked me to simplify it by adding a SOAP interface. I have not been able to persuade them that XML encoded as a string embedded in a request encoded as XML whose response is XML that must be parsed is in fact more complex than just POSTing the XML you started with and checking a 3-figure status code.
Posted by Damian Cugley on 2009-04-20
This nails it for me.
Posted by Phil Wilson on 2009-04-21
Posted by Robert Brewer on 2009-04-18