Partial response and partial update are now available for the YouTube Data API, the Calendar Data API and the Picasa Web Albums Data API. The Sidewiki Data API currently only supports partial response.

You can find a more detailed description of these new features here.

Why is Google doing this? Because the more powerful web applications become, the more important Google's search, browser and nascent OS become. More relevant to developers than some grand anti-Microsoft conspiracy, though, is that some serious UI sweetness may be forthcoming.

The Closure Compiler will scrunch up your weighty javascript for super-efficient deployment, allowing you to do more in the user's browser with a much smaller code payload to deliver. The compiler is available in binary, as a web app and as an API. Google is also releasing a Firebug extension called Closure Inspector that will translate those compiled bits of code back into their original format.

The Closure Library is a collection of cross-browser, modular, "industrial strength" UI components from across the various Google properties. Rich text editor, DOM inspector, drag and drop ala Google Maps - you want it, you got it.

Also released are a number of high-efficiency Closure Templates.

Google's Amit Agarwal says that all of the above were originally built as "20% time" projects but then became fundamental parts of some of the most popular Google applications. Now these technologies can be used in building your apps, as well.

It will be interesting to see how these Google offerings stack up and get adopted compared to Yahoo's YUI library.

Perhaps nothing like this should be a surprise coming from a company that built the leading webmail product online and still calls it Beta five years later.

Who's worn the virtual cap and gown already? Twenty seven projects are listed as graduates, including the YouTube APIs, Maps APIs and (thank goodness) Contacts API. We've been wondering why more developers aren't using the Contacts API but instead keep asking us for our precious Google passwords. It's been out for a whole year now. Now there can be no excuse! The Contacts API is real, it's solid and Google is committed to supporting it.

Surprises among the 18 projects still deemed too green for prime time? Gears, Finance Data APIs, Social Graph API and the Feedburner APIs.

Google APIs are an incredible resource and today's announcement should further their adoption. We'll be monitoring the Code Labs page for the experimental availability of the inevitable Google Brain Implant API, but until that day comes we feel almost unconditionally excited about the code projects the Google teams are working on.

That day has come. The Google Contacts API went live tonight and it enables far more than just contact transfer.

• Synchronize Google contacts with contacts on a mobile device
• Maintain relationships between people in social applications
• Give users the ability to communicate directly with their friends from external applications using phone, email, and IM

"The Contacts API allows developers to create, read, update, and delete contacts using the Google Data protocol, based on AtomPub," the announcement says. "It also allows for incremental sync by supporting the 'updated-min' and 'showdeleted' parameters."

Pretty hot read/write stuff and particularly interesting given today's developer launch of the location tracking Fire Eagle from Yahoo!

One thing Fire Eagle has going for it that the Google Contacts API does not is support for the open authentication standard oAuth. Support by Google for oAuth in this API would have reduced the work required for developers by allowing code from other authentication proccesses to be reused. Google is supporting oAuth in OpenSocial, but on some days that hairball is harder to get excited about that a nice simple API like this one that delivers clear value.

Today's a big day for developers, may the secure Gmail contact leveraging begin!