[occi-wg] Microsoft: "Atom Publishing Protocol (AtomPub) as the future direction"

[Alexis Richardson]

Sam,

That's a great spot - thanks for posting it.

I'm not convinced that MS claims for 'REST' stand up under scrutiny,
but it is interesting to see AtomPub getting a boost.

I thought this was quite interesting too:
http://www.defuze.org/archives/171-atom-and-atompub-were-failed.html

a



On Tue, May 12, 2009 at 12:01 PM, Sam Johnston <samj at samj.net> wrote:
> Afternoon all,
>
> I'm surprised this slipped by before but while re-reading Joe Gregorio's
> recent controversial rant on AtomPub I spotted this comment which explains:
>>
>> 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.
>
> Interesting choice of "POX" as in "Plain Old XML", thus avoiding the
> XML-RPC/SOAP stigma... but we digress... this post 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)
>> and the Atom Publishing Protocol (RFC 5023). 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 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.
>
> The developer docs 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". This is interesting because it was a move from away from a
> "simple XML" type rendering (example) 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 go. According to Bill de hÓra:
>>
>> One upside is that adopting Atom protocol 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
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>