Atom Publishing Protocol

~ the eulogy ~

The IETF's atompub working group, chaired by Paul Hoffman and Tim Bray, had already done the famous half of its job. RFC 4287 in December 2005 defined the Atom feed format, the one that spent a decade losing a popularity contest to RSS. The second half arrived in October 2007 as RFC 5023, edited by Joe Gregorio and Bill de hÓra, and it described how to write to a website rather than read from it: service documents advertising what collections exist, then ordinary HTTP verbs against them. The group concluded afterward and never met again.

The problem it was aimed at was real, and annoying enough that people kept trying to solve it. If you wanted to build a desktop app that posted to blogs in 2006, you implemented the Blogger API and then the MetaWeblog API and then whatever MovableType had bolted on top of MetaWeblog, all of it XML-RPC and all of it slightly different about slightly everything. AtomPub was the committee answer: one vocabulary, discoverable, with the server telling the client what it could do.

WordPress is where you can watch the verdict come in, because WordPress counted. Core ticket 21866 proposed removing AtomPub, and the argument was traffic: a couple of hundred posts a day across tens of millions of sites, against hundreds of thousands over the XML-RPC endpoint nobody was defending on elegance. WordPress 3.5 shipped on 11 December 2012 with wp-app.php and class-wp-atom-server.php deleted. Anything still calling the endpoint got a 403, and a plugin was published for the handful of people that broke.

~ who actually shipped it ~

Google was the big one. The GData framework wrapped Atom and AtomPub around most of the company's public APIs in the late 2000s, so for a while Calendar, Blogger, YouTube and Contacts all spoke it. If you wrote anything against a Google service between about 2007 and 2012, you have parsed an Atom entry whether or not you knew the protocol had a name.

Microsoft shipped it twice over. Windows Live Writer used AtomPub to talk to blogs, which made it the closest thing the protocol ever had to a consumer face, and OData's first three versions used Atom as their wire format before version 4 made JSON the default in 2014. TypePad and a long tail of Java and .NET content systems had endpoints too.

The pattern in all of it is the same. Everybody implemented AtomPub as a compatibility layer for somebody else's client, and nobody built anything new on top of it, so when the clients went the endpoints had no constituency left to argue for them.

~ the dossier ~

~ the last endpoint ~

Blogger was the final holdout, which is fitting, since Blogger's own 2003 API was one of the dialects AtomPub existed to replace. Google's deprecation notice gives the date plainly: version 2.0 of the Blogger GData API was scheduled for shutdown on 30 September 2024, with version 3.0 and its JSON responses as the replacement. The notice describes GData as "one of Google's old APIs" and says almost all the Google APIs that used it are already deprecated or moved. The GData Admin Settings API had gone the same way on 31 October 2018.

Nothing was ever withdrawn. RFC 5023 is still a Proposed Standard, and the only document that has ever updated it is RFC 8996, a blanket deprecation of TLS 1.0 and 1.1 that swept through dozens of unrelated specs at once. I have written against a lot of APIs and I have never once needed to fetch a service document to find out what I was allowed to POST to, which is the whole idea, and it is the part the industry declined. The protocol is sitting in the RFC index in perfect health, with no server left anywhere that will answer it.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »