During his presentation at the developer conference, Benioff
showed a demo in which all of the Google definitions, such as its
calendar, could be read into the Eclipse IDE and then used to build Force.com apps.
The Google data APIs are built on top of the Atom publishing protocol, a more modern version of the RSS protocol used to syndicate newsfeeds.
Using them, developers will be able to access Google Data APIs directly from Salesforce.com's APEX programming language"
Apex will call Google via GData/AtomPub, Google won't serve up the Apex formats (should be a heck of a lot better than the SOAP approach Apex uses).
So far the API services available to Apex clients are:
Google Documents API
Google Calendar API
Google Spreadsheets API
Blogger API
Contacts API
Google Data Authentication
The dump format exposed via the Apex client looks a bit weird (not quite JSON); hopefully it's not what's going over the wire or can be negotiated using a format parameter/Accept header to avoid compability problems.
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.
Also interesting that they're using multipart related to optionally upload an Atom Entry along with media content: "Documents are uploaded to the server via an HTTP POST optionally using
MIME multipart encoding to combine the the document contents with a
Atom entry describing the document." - I wonder if that's based on the 'Picasa style' multipart uploads which are going to be standardized on the AtomPub working group.