Google Data APIs Protocol

Google has released their very akwardly named Google Data APIs Protocol, which we'll just abbreviate to GData. GData is, for all intents and purposes, an Atom Store, that is, an Atom Publishing Protocol service mixed with OpenSearch. I haven't had time to write code against it yet, and I'm still reviewing the documentation, but it looks like what they have published is compliant to the latest version of the APP. I don't see an introspection document to list out the multiple feeds/collections which exist but you have to hand construct the URIs, entries are returned in the response after a POST (currently ambiguous in the APP spec and being discussed), and there's excellent and proper use of the atom:link elements throughout. Summary: there are some minor rough spots but it looks very good.

There are some general comments I can make right away and they relate to this table:

There was a conscious decision to not make searching/queries a core part of the APP but to put those in a separate specification, ala OpenSearch. The same can be said of Authentication, it's acknowledged that Basic and Digest aren't cutting it, but creating a new authentication scheme was outside the scope of the AtomPub WG and work is progressing in other venues.

The final point is with respect to Optimistic Concurrency, here they are talking about Detecting the lost update problem which can be solved by using ETags and If-Match headers as outlined in that W3C note, or you can make a new edit URI for each version of the entry, which is the method they chose. Both are valid and both work with the current APP specification. So of the three N's in the Atom column I would say that 'Optimistic Concurrency' is a Y, 'Queries' is a N right now but may be a Y in the future, and 'Authentication' shouldn't even be in the table.

Found via DeWitt.

Update: The first thing you run into with GData is the authentication scheme. It's close, and only needs a couple tweaks to be much better. First, attempting an unauthorized operation results in a 401 response, which is excellent, and it includes a WWW-Authenticate header:

  WWW-Authenticate: GoogleLogin realm="https://www.google.com/accounts"

There are two changes that would make that better. First, the URI you have to POST to to authenticate is actually https://www.google.com/accounts/ClientLogin and that's what should be returned in the realm. Secondly, a 'service' parameter is needed when you login and that could also be returned in the WWW-Authenticate: header. So if we tried an operation on the calendar service without authentication it should respond with:

 WWW-Authenticate: GoogleLogin realm="https://www.google.com/accounts/ClientLogin", service="cl"

Where 'cl' is the value for the calendar service.

Update 2: I have added very crude support for GoogleLogin to httplib2 in subversion on the trunk, and by crude I mean does little to no error checking. But it does work and makes dealing with the calendar protocol easier:

import httplib2

h = httplib2.Http()

name, passwd = file("/home/jcgregorio/xxxx", "r").read().split()
h.add_credentials(name, passwd)
headers = {'Content-Type': 'application/atom+xml'}
body    = "<...>"
uri     = "http://www.google.com/calendar/feeds/default/private/full"
resp, content = h.request(uri, "POST", body=body, headers=headers)
if resp.status == 302:
    resp, content = h.request(resp['location'], method="POST", body=body, headers=headers)

print resp, content

• google
• atom
• app
• opensearch
• gdata
• atomstore