At Google, we strive to make the web faster. Today, we’re proud to take our first big step in making APIs faster by introducing two experimental features in the Google Data Protocol, partial response and partial update. Together, partial response and partial update can drastically reduce the network, memory, and CPU resources needed to work with Google APIs.

It’s easy to understand the benefit of partial response and partial update. Imagine that you are writing a new Android calendar widget, and you want to display the time and title of the recently changed events on your Google Calendar. With the old Calendar Data API, you would request your calendar’s events feed and receive a large amount of information in response -- including lots of extra data like the attendee list and the event description.

With the addition of partial response, however, you can now use the fields query parameter to request only relevant information -- in this case, event titles and times. Constructing such a request using the fields query parameter is simple:


By including the entry argument and specifying title and gd:when, this request ensures that the partial response contains only the title and time for each event, along with a small amount of wrapping metadata.

But say you want to also enable the widget to change the time of calendar events. With partial update, you can easily accomplish this: simply edit the data you received in the partial response and use the HTTP PATCH verb to send the modified data back to the server. The server then intelligently interprets your PATCH, updating only the fields you chose to send. Throughout this entire read-modify-write cycle, the unneeded data remains server-side and untouched.

Now for a quick demo. If you’re currently logged into a Google account, compare the size of your full calendar feed and your partial calendar feed. When we ran this test, our full calendar feed contained 160 kB of data while the partial feed only contained 8 kB -- the partial response successfully reduced total data transfer by 95%! Performance enhancements like this are especially apparent on a mobile device, where every byte of memory and every CPU cycle count. In nearly all clients, partial response and partial update make it more efficient to send, store, parse, cache, and modify only the data that you need.

As of today, partial response and partial update are supported in four Google APIs:
... and we’re planning on adding support for most of the APIs that are built on the Google Data Protocol soon. Stay tuned for more information, and if you can’t wait, feel free to lobby for partial update and partial response in your favorite API’s public support group. And for those of you who’ll be at Google I/O this year, be sure to check out the Google API sessions that are in store.

Thanks for joining us in our effort to make APIs on the web as fast and as efficient as possible!

Today, we are happy to announce the launch of AuthSub for ActionScript, a new component of the well-known AuthSub authentication interface for the Google Data Protocol. This new feature enables Flash and Silverlight applications to access data securely on behalf of a user, without the application ever seeing the user’s private login credentials.

To use AuthSub for Actionscript (or as we’re calling it, AuthSubAS), first ensure that the API you are accessing offers cross-domain support. To do this, simply check for a crossdomain.xml file like those offered by the Picasa Web Albums Data API and the YouTube Data API. Then, if the API supports cross-domain scripting, you can simply point your Flash app to{Request,SessionToken} and authenticate. If you’re familiar with how AuthSub for JavaScript works, AuthSubAS works in much the same way. For more information, see the AuthSub for ActionScript guide and check out this code sample.

Currently, cross-domain requests are only supported by the Picasa Web Albums Data API and the YouTube Data API.  However, as more APIs offer cross-domain scripting through an open crossdomain.xml file, the AuthSubAS authentication will work automatically. For questions about a specific API or to encourage your API to provide AuthSubAS support sooner, visit your API’s support group in Google Groups.

By Detlev Schwabe, Software Engineer

Many developers and partners use the Picasa Web Albums Data API to enable users to upload photos to Picasa from web sites and desktop applications. Now, we are excited to announce the same PWA Data API can be used to upload videos to Picasa Web Albums as well!

The API commands for uploading videos are similar to those you may already use to upload photos. You can upload videos up to 100MB in AVI, QuickTime, MPEG4, WMV and other formats. The system will automatically create a thumbnail image to represent the video, or you can choose one yourself at any time.

There are many ways you can use video uploading, including enabling users to upload all the content from their cameras — including still images as well as videos — all to Picasa Web Albums at the same time. And, of course, the Video Uploader API is the perfect way to integrate dedicated webcams with Picasa!

The Video Uploader API is part of the standard Picasa Web Albums Data API. You can find the updated documentation here.


I had the pleasure of taking a trip back to my home land of England to meet up with the team behind the Google Gears for Mobile product.

As someone who loves Web development, it is an exciting proposition to be able to use the Web platform to be able to develop applications on the mobile.

This release enables you to use the Gears 0.3 APIs on Windows Mobile devices. With this new version, not only do you have access to the Database, LocalServer, and WorkerPool APIs, but you can also create desktop shortcuts. Considering the disconnected nature and latency issues inherent to the mobile networks, these APIs allow you to deliver more responsive applications that can hide some of the problems.

Today, we saw the release of a new mobile version of Picasa Web Albums that uses these features. I got to sit down with Joe Walnes, tech lead of the mobile Picasa team. Joe and his team built both the Gears-enabled version of Picasa for the phone as well as the iPhone version that allows you to sit on the Tube and still flip through your family photos.

Joe tells us about his experience building the Gears application.

I have also put together an audio podcast consisting of interviews with not only Joe, but other members of the Gears team.

First, I talk to Charles Wiles, the Product Manager of the Google Gears for Mobile team. He gives us a high level view of the project in general, and this launch in particular. We also discuss the native abilities of Gears on the mobile, widget platforms, and future Gears developments.

Second, we hear from two engineers on the project, Dave Burke and Andrei Popescu. They go into detail on the platform, how you architect mobile Web applications, how you develop and debug applications, new APIs such as the Location API, and how Android fits in to the picture.

Finally, we hear again from Joe Walnes.

I am really excited about the prospect of building rich mobile applications using Web based technology.

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).


The Picasa Web Albums team is pleased to announce the release of the newest member of the GData family, the Picasa Web Albums data API.

Now you can access your albums, photos, comments and tags through a common GData API. Have a great idea for integrating your photos and tags into a semantic network? Want to add a slide show of your favorite photos to your homepage and include user comments? How about autotagging your photos based on image analysis or photo description or title? Or allowing users to pick a Picasa Web Albums photo from inside your application? The possibilities are endless.

We're excited to see what great ideas the developer community comes up with for the Picasa Web Albums data API. We hope this newest installment gives you the freedom to make the killer application you always wanted, and as always we encourage comments, questions and criticisms. Tell us what you think.