Afternoon all, I'm surprised this slipped by before but while re-reading Joe Gregorio's recent controversial rant <http://bitworking.org/news/425/atompub-is-a-failure> on AtomPub I spotted this comment<http://bitworking.org/news/425/atompub-is-a-failure#X2>which explains:
Microsoft is migrating all of its Live Services APIs<http://msdn.microsoft.com/en-us/library/bb264574.aspx>into a single unified AtomPub API in the Live Framework <http://dev.live.com/liveframework/>. 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.
Interesting choice of "POX" as in "Plain Old XML", thus avoiding the XML-RPC/SOAP stigma... but we digress... this post<http://dev.live.com/blogs/devlive/archive/2008/02/27/213.aspx>from a Microsoft VP leaves little to the imagination:
Atom Publishing Protocol (AtomPub) as the future direction
Microsoft is making a large investment in unifying our developer platform protocols for services on the open, standards-based Atom format (RFC 4287<http://www.ietf.org/rfc/rfc4287.txt>) and the Atom Publishing Protocol (RFC 5023<http://www.ietf.org/rfc/rfc5023.txt> ). At MIX we are enabling several new Live services with AtomPub endpoints which enable any HTTP-aware application to easily consume Atom feeds of photos and for unstructured application storage (see below for more details). Or you can use any Atom-aware public tools or libraries, such as .NET WCF Syndication <http://msdn2.microsoft.com/en-us/library/bb412202.aspx>to read or write these cloud service-based feeds.<snip>
The intent for these early, experimental releases are to gather valuable feedback from the community around our idiomatic and freely licensed extensions to AtomPub which deal with important service scenarios, such as URL formats, nested directories, image streams, and service metadata. You can read more about this on the Project Astoria team blog<http://blogs.msdn.com/astoriateam/archive/2008/02/13/atompub-support-in-the-ado-net-data-services-framework.aspx> .
The developer docs <http://msdn.microsoft.com/en-us/library/dd137315.aspx>further explain:
AtomPub was chosen as the base-level interaction protocol for CRUD operations on Live Framework resources. Using a community-supported interpretation of Representational State Transfer (REST) and its interaction model for exchanging feed-based representations enables a variety of basic AtomPub clients, applications, and tools to interact with the Live Framework.
It's worth noting that in a "big switch in direction" and "huge endorsement for AtomPub " "Microsoft dropp[ed] Web3S for AtomPub for Windows Live! service APIs<http://www.xlml.com/aehso/2008/02/29/microsoft-dropping-web3s-for-atompub-for-windows-live-service-apis/>". This is interesting because it was a move from away from a "simple XML" type rendering (example <http://dev.live.com/livedata/web3s.htm#_Toc165288985>) previously proposed here for OCCI towards AtomPub with a light, standardised structure. Apparently Salesforce are getting in on the game too, at least in so far as their integrations with Google<http://wiki.developerforce.com/index.php/Google_Data_API_Toolkit>go. According to Bill de hÓra<http://www.dehora.net/journal/2008/06/24/salesforcecom-and-google-integration-atompub/> :
One upside is that adopting Atom protocol<http://wiki.apexdevnet.com/index.php/Google_Data_API_Toolkit>and the associated HTTP-like-it-oughta-be approach a should help salesforce.com stop creating multiple incompatible APIs on top of the many (~18?) they have already (apparently these APIs account for 45% of sf.com's transactions). Or at least slow that kind of unneccessary churn down.
Salesforce's API has been around for so long that it's still SOAPy but I would not be surprised to see this change at some point... an open standard that delivers the extensions that Google and Microsoft felt necessary to add could well be all it takes to get them on board too (while they don't offer infrastructure, they do offer platform services and that's the logical progression for OCCI). Sam