Blogger API, Version 2.0

So, a developer preview of the version 2.0 Blogger API was posted tonight.

First impression: it works well for Blogger (and not necessarily everyone else). And that's not a bad thing, of course--this is the Blogger API. But note that, in the case of Movable Type, our interest in this matter is in hoping that tools originally built for the Blogger API can be also used for MT-powered blogs without the loss in functionality that currently exists. With that in mind, some of the missed opportunities for interoperability are a bit disappointing.

My thoughts and possible suggestions:

• Structs have been added as arguments to many of the method calls, replacing the positional arguments that were previously there. This is a good thing, and along the lines of the metaWeblog API's post struct. (An aside: it might have been smarter, though, to adapt some of the naming conventions for fields used in the metaWeblog API: using date vs dateCreated, body vs description, etc, seems like change for change's sake, particularly when Blogger was the one who used dateCreated in the first place in the first version of the API.) However, the use of structs does not extend to getTemplate, which means that systems with multiple template types, numeric IDs instead of just template names, etc. cannot use getTemplate/setTemplate. But perhaps templateName could be co-opted to be a template ID instead?
• The filters struct for blogger.getRecentPosts is a nice encapsulation of different search techniques. There are a couple of search parameters included: by date, by post ID, by post status (draft/publish). But why no offset parameter? That would seem to be the most obvious search "parameter", allowing you to iterate over an entire set of posts without having to fuss with dates. And of course, getRecentPosts is now sort of a misnomer, because with the added filters, one will not always be retrieving recent posts, I assume. Which leads to...
• This API is completely incompatible with version 1.0 clients and the version 1.0 server implementation. I assume that the 2.0 server will use a different XML-RPC endpoint, so that 1.0 clients will not be broken (this isn't mentioned in the preview notice, though). But it leads to this point: with an incompatible API, why use the same method names? As I understand it, blogger.getRecentPosts will no longer return the most "recent" posts--it will return, essentially, the results for the filtered search. blogger.searchPosts might be a better name, or perhaps just blogger.getPosts. The only thing I can think of--other than an oversight--is that getRecentPosts will still only return the N most recent posts (limited by some upper ceiling on N, as in the version 1.0 API), where the filters are used to filter only those results. This would be rather disappointing.

What I would have been interested to see, aside from the above-mentioned complaints, is a revamped authentication system. The token field for the login struct is enticing--perhaps it's an untamperable session token that removes the necessity to pass username and password unencrypted over HTTP? But of course, nothing like that is mentioned on the rest of the page, and if the API is backwards-incompatible anyway, why not remove the username/password authentication entirely? At the very least, perhaps the password can be one-way hashed using MD5 or SHA-1?

On the whole, it's good to see the API moving again. From our standpoint, of course, we'd love to see some of the above issues addressed, but any progress on their part is good for getting the ball rolling.

Update: updates on the API and thoughts on an authentication mechanism.