Getting organized with the Tasks API

Cross-posted from the Google Apps Developer Blog

Google Tasks helps many of us to remember all those things that keep us busy. Towards the end of last year we asked our users what they wanted to see improved with Google Tasks and an overwhelming request was for the ability to access tasks from anywhere — be it on the move, on the desktop, or through their favorite Web apps.

Today, we’re checking off a big to-do from our list and are inviting you to try out the new Google Tasks API. Using the Google Tasks API, developers can — for the very first time — create rich applications which integrate directly with Google Tasks.

The Google Tasks API provides developers with a powerful set of API endpoints for retrieving and modifying Google Tasks content and metadata. It offers a simple, RESTful interface and supports all basic operations required to query, manage and sync a user’s tasks and task lists. The API uses JSON for data representation and works with multiple authentication mechanisms including OAuth 2.0.

Plain HTTP using JSON	Using Google API Client Library for Java
POST /tasks/v1/lists/<list-ID>/tasks Content-Type: application/json ... { title: "Publish blog post" }	Task task = new Task(); task.setTitle("Publish blog post"); client.tasks.insert( "list-ID", task).execute();

Client libraries are provided for several major programming environments and should help you get up and running quickly.

The API is available in Labs and can be activated for your project through the API Console. Get started today by trying the Tasks API yourself using the API Explorer and taking a look at the documentation.


If you want to see the API in action check out the Google Tasks Chrome Extension. If you are at Google I/O we invite you to come along and hear the Google Tasks team talk about the new API today.

We thank the early adopters that have worked with us and built their own Google Tasks integrations over the last weeks. We’d like to highlight a few of them:

• Producteev is a task management platform that lets teams and individuals access their to-dos from a lot of different locations (web, mobile, email, calendars...). You will now have all your Producteev's tasks available in Google Tasks and vice versa!
• Mavenlink's project collaboration suite allows you to communicate, share files, track time, invoice, and make or receive payments in one place. With its Google Tasks integration, your Mavenlink project tasks & Google Tasks always stay in sync.
• Manymoon is the top installed social task and project management app in the Google Apps Marketplace and makes it simple to get work done online with co-workers, partners, and customers. Manymoon's users can now create and view tasks with Gmail and Google Calendar through Google Tasks.
• Zoho offers a suite of online business, collaboration and productivity applications for small businesses. So far they have integrated Zoho CRM & Zoho Projects with the Tasks API.

Get Started with the Google Tasks API today!

Want to weigh in on this topic? Discuss on Buzz

Posted by Fabian Schlup & Nicolas Garnier Google Tasks API Team

Google Prediction API helps all apps to adapt and learn

By Travis Green, Product Manager

Now your apps can get smarter with as little as a single line of code. They can learn to continually adapt to changing conditions and to integrate new information. This week at Google I/O, we’re making the Google Prediction API generally available, meaning you can create apps with these capabilities for yourself. Additionally, we’re introducing several significant new features, including:

• The ability to stream data and tune your predictive models
• A forthcoming gallery of user-developed, pre-built models to add smarts even faster.

The Google Prediction API can be used by almost any app to recommend the useful, extract the essential, and automate the repetitive. For example:

• Recommend a new movie to a customer.
• Identify most important customers.
• Automatically tag posts with relevant flags.

For example, Ford Motor Co. Research is working to use the Prediction API to optimize plug-in hybrid vehicle fuel efficiency by optionally providing users with likely destinations to choose from, and soon, optimizing driving controls to conserve fuel. Because the API is a cloud-hosted RESTful service, Ford has been able to access its computationally-intensive machine learning algorithms to find patterns that rank potential destinations based on previous driving paths. Ford will be demonstrating their work at the API’s I/O Session.

Here’s a summary of the features we added to the API today:

• Streaming training data: Continually incorporate feedback for fast-adapting systems (e.g. user-chosen tags vs predicted ones, final purchases vs expected).
• General availability: Anyone can now sign up to use the API. Paid users also receive a 99.9% SLA with increased quota.
• New JavaScript library: Now deploy the Prediction API in your JavaScript – in addition to our updated Python and Java libraries.

Today, we are also announcing the Prediction API’s forthcoming gallery of pre-trained third party predictive models (try these demo models right now), and we will be adding more constantly (maybe yours – waitlist). Once complete, all Prediction API users will be able to:

• Subscribe to others’ models: improve your apps with others’ predictive data tools.
• Sell access to your models (e.g. sentiment analysis on social media).
• Import customized models through the open-standard PMML encoding.

See our recent blog post for even more ideas, and get started at the Google APIs Console.

Thanks to our community of preview developers, who have played a crucial role in helping us make the Google Prediction API simpler and more powerful since its announcement last year at I/O 2010. We are thrilled to invite all developers to join them.


Travis Green's favorite part about his job is designing smart applications. In his spare time, he is in the great outdoors (looking for trouble).

Posted by Scott Knaster, Editor

Google APIs Discovery Service: one API to find them all

Anton

Monsur

Joe

By Anton Lopyrev, Monsur Hossain, and Joe Gregorio, Google Developer Team

As announced at last Google I/O, the new family of Google APIs client libraries runs on top of a brand new API infrastructure, which allows Google to reduce the amount of work needed to release and maintain the client libraries. This is done through a simple API that provides machine readable descriptions of Google APIs that the client libraries take advantage of.

Today, we are announcing the Google APIs Discovery Service, which is the secret sauce behind the new client libraries. This service exposes machine readable metadata about Google APIs including:

• A directory of supported APIs.
• A "Discovery document" for each of the supported APIs that includes:
• A list of API resource schemas based on JSON Schema.
• A list of API methods and available parameters for each method.
• A list of available OAuth 2.0 scopes.
• Inline documentation of methods, parameters, and available parameter values.

The service is accessible through a lightweight JSON-based API. Navigate your browser to https://www.googleapis.com/discovery/v1/apis to get a quick look at the available data.

You can use the APIs Discovery Service to build tools for interacting with Google APIs, such as IDE Plugins and client libraries. We use the service at Google to build a number of such tools:

• Google APIs client libraries - as described above
• Google APIs Explorer - an interactive web-based tool for exploring Google APIs
• Google API Support in Google Plugin for Eclipse - an IDE integration that allows you to import Google APIs support directly into your Eclipse project

With the launch of this service, we are also open-sourcing the code for the APIs Explorer, which can serve as a great example of how to use the service.

Read more about Google APIs Discovery Service in the documentation, or explore its API in the APIs Explorer. If you are attending this year’s Google I/O and you want to know more about the service, make sure to attend our session “Building Custom Client Libraries for Google APIs” where you can chat with the developers of the service face-to-face.

We look forward to seeing what sorts of things you can build. Let us know of any issues and feature requests in our developer forum. Happy hacking!


Anton Lopyrev is an Associate Product Manager for Google APIs Infrastructure, previously a software engineer on Street View. He is a computer graphics enthusiast who is also passionate about product design.

Joe Gregorio is a Software Engineer. In the past four years at Google he’s worked on APIs, Google App Engine, Google Wave, and now has come full circle and is back working on APIs.

Monsur Hossain is a Software Engineer for Google APIs Infrastructure and enjoys making it easier to use APIs.

Posted by Scott Knaster, Editor

Prediction API: Every app a smart app

By Travis Green of the Google Prediction API Team.

If you’re looking to make your app smarter and you think machine learning is more complicated than making three API calls, then you’re reading the right blog post.

Today, we are releasing v1.2 of the Google Prediction API, which makes it even easier for preview users to build smarter apps by accessing Google’s advanced machine learning algorithms through a RESTful web service.

Some technical details of the Prediction API:

• Chooses best technique from several available machine learning algorithms.
• Supported inputs: numeric data and unstructured text.
• Outputs hundreds of discrete categories, or continuous values.
• Integrates with many platforms: Google App Engine, web and desktop apps, and command line.
• v1.2 improvements:
• Simpler interface: automatic data type detection, and score normalization.
• Paid usage tier.
• Improved usage monitoring and faster signup through the APIs Console.

Ideas to make the most of the Prediction API:

• Recommendation: What products might a user be interested in? (example)
• Filter RSS feeds, user comments, or feedback: Which posts are most relevant? Should a user comment be featured? Which feedback should we look at first? (example)
• Customize homepages: Predict what content a user would like to see and populate the page with the user’s anticipated interests.
• Sentiment analysis: Is this comment positive or negative? Does a commenter support Group A or Group B?
• Message routing: Route emails to the appropriate person based on analysis of the email contents.
• See the Prediction API website for many more!

To join the preview group, go to the APIs Console and click the Prediction API slider to “ON,” and then sign up for a Google Storage account.

We would also like to continue to thank our supportive preview users for their help making the API the service it is today. We look forward to seeing many more of you join us in making the web just a little bit smarter, and hearing your thoughts and feedback through our discussion group.

Travis Green's favorite part about his job is designing smart applications. In his spare time, he is in the great outdoors (looking for trouble).

Posted by Scott Knaster, Editor

Google APIs Python Library goes to Beta

This post is by Anton Lopyrev and Joe Gregorio.
Anton Lopyrev is an Associate Product Manager for Google APIs Infrastructure and was previously a software engineer on Street View. He is a computer graphics enthusiast who is also passionate about product design.



Joe Gregorio is a Software Engineer. In the past four years at Google he's worked on APIs, then Google App Engine, then Google Wave, and now has come full circle and is back working on APIs. -scottk


Over the last several months we have launched a number of tools, such as the Google APIs Explorer and the Google APIs Console, that help you explore Google APIs based on our brand new API infrastructure and manage your API access directly in your browser. However, most of the day-to-day usage of the APIs is still via client libraries in various programming languages.

Today, we are announcing a major milestone for one of the Google APIs client libraries. The Google APIs Client Library for Python has officially reached Beta. This means that we're comfortable enough with the stability and features of the library that we'd like you to start building real production applications on top of it and send us your feedback. Client libraries in other languages are soon to follow.

If you are interested in getting more familiar with our new client libraries, we hope to see you at the “Introduction to Google APIs” lecture at I/O Bootcamp and the “Life of a Google API Developer” session at Google I/O, where you can chat with the developers of the libraries face-to-face.

Best Practices for User Authentication

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:


Error=BadAuthentication
Info=InvalidSecondFactor


There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations

Improving the security of Google APIs with SSL

We at Google go to great lengths to ensure every step is taken to protect our users’ data. As part of our ongoing effort to improve security everywhere, we will start requiring the use of SSL in many products. Requiring SSL improves security by encrypting data communications between users and Google, better protecting it from being intercepted by a malicious third party.

Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.

Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.

This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.

Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.

If you have any questions or concerns about this change, please follow up in the forums of the API you are using.

By Adam Feldman, Google Developer Team

Introducing the Google APIs Explorer

Google is always looking for new ways to make it easier for developers to get started with our APIs. When you come across a new Google API, you often want to try it out without investing too much time. With that in mind, we are happy to announce the Google APIs Explorer, an interactive tool that lets you easily try out Google APIs right from your browser. Today, the Explorer supports over a half dozen APIs – and we expect that number to grow rapidly over the coming weeks and months.

By selecting an API you want to explore, you can see all the available methods and parameters along with inline documentation. Just fill out the parameters for the method you want to try and click “Execute”. The Explorer composes the request, executes it, and displays the response in real time. For some APIs that access private data you will need to “Switch to Private Access” and authorize the Explorer to do so.

To get you started, here are some sample requests; follow the links and press “Execute”:

• Expand a goo.gl URL using the URL Shortener API
• Translate a phrase to French using the Translate API
• List your personal Buzz posts using the Buzz API (requires private access)

The Explorer makes it easier for developers to discover what APIs we offer and get started using them within minutes. If you have any questions or comments, visit the help page or the support forum. We’d love to hear your feedback.

Happy exploring!

By Anton Lopyrev and Jason Hall, Google Developer Team

New Shopping APIs and Deprecation of the Base API

We are pleased to announce our newest addition to the shopping family -- a simple yet powerful programmatic interface that enables retailers to upload their content to Google and query data from Google. The new Shopping APIs have two components: Content and Search. As part of this launch, we’re are also deprecating the Base API and replacing it with today’s new Shopping APIs.

The Content API for Shopping allows retailers to upload product data to Google for use in multiple places online like Google Product Search, Product Ads, Google Affiliate Network, Google Commerce Search, and Shopping Rich Snippets.

The Search API for Shopping makes it easy for our Google Commerce Search customers, Google Affiliate Network publishers, and developers to build innovative applications using product data.

The Shopping APIs replace the Base API
These new Shopping APIs replace the existing Google Base Data API for our content providers and search applications. We are deprecating the Base API and will fully retire it on June 1, 2011. For existing developers making the switch, we’ve provided a Migration Guide to help.

You can read more details about these announcements on the Google Merchant Center blog and our FAQ on Google Base Data API Deprecation.

By Alex Dovlecel and Andrew Eames, Google Shopping Team

Introducing the Google APIs Console and our latest API updates

After a busy year of creating, curating, and re-organizing our APIs, we’re pleased to share that:

• We’re announcing the Google APIs console, a new tool to help you use our APIs in your applications and on your websites.
• We’re introducing a new and improved Custom Search API and the new Translate API, which replace the old Web Search API and the old Translate API respectively, which are being retired along with the old Local Search API.
• We’ve reorganized and rewritten the documentation for some of your favorite APIs (read more on the AJAX APIs Blog).

New Google APIs Console Improves API Experience

The new APIs console helps you manage your API usage across all of your sites and apps. Key features include:

• Log in with your Google account to see the API projects you’re working on.
• Create and manage project teams for projects that are shared with your co-workers or friends.
• Get developer credentials to track exactly how you are using each API.
• View information about how your site or app is using the APIs, including which of your pages are making the most requests.

Initially, the console supports over a half dozen APIs – that number is expected to grow rapidly over time. Please take a look at the APIs console and get started using Google’s new APIs today.

New Custom Search API Delivers Better Integrated Search Experience

Google Custom Search helps you create a curated search experience, tailoring a custom search engine precisely to your specifications. This is the perfect tool for helping your visitors find exactly what they’re looking for on your site, and is especially useful for businesses that want to create a customized search experience across their public content without the expense or hassle of developing and hosting their own search infrastructure.
Today we are enhancing our Custom Search offering with the introduction of new output formats and a new API. Now, in addition to using the Custom Search element or the XML API, the new API offers search results using your choice of Atom or JSON syndication formats. To get started, click here to log into the API console and add this API to your project.

Retirement of Older APIs

As part of our ongoing housekeeping of our first-generation APIs, the legacy Web Search API and the Local Search API are being retired, to be phased out over the next three years as per our deprecation policies. We’ll also be tightening up our enforcement of the rate limits for these and the Translate API v1 over the next few months with an eye toward mitigating unauthorized usage, so we encourage everyone to migrate to the new APIs as available on the APIs console, or over to the Custom Search Element, the Translate Element, or the Maps API GoogleBar as your needs dictate.

Looking Forward

We’re excited about the opportunities that the new APIs console and this first batch of APIs built on our new API architecture will offer to developers. Even though we’ve been building APIs for several years now and are quickly approaching 100 tools, products, and APIs for developers, we still feel like we’re just getting warmed up. We’d love to hear your feedback on the new Google API console and our newest APIs — please let us know what you think.

By Adam Feldman, Adam Winer, David Gibson, and Louis Ryan, Google Developer Team

Introducing the Google Buzz API

With Google I/O 2010 finally upon us, what better time to introduce developers to the latest updates to the Google Buzz API?

As announced at the launch of Google Buzz, the Google Buzz API aligns itself with the ever-growing family of freely available and community-developed protocols, formats, and standards for sharing and consuming social content on the web, including ActivityStreams, Atom, AtomPub, JSON, OAuth, PubSubHubbub, MediaRSS, PortableContacts, and more.

The Google Buzz API, a member of the Google Code Labs, is very much a work in progress — we intend to continue to iterate out in the open as we go along — and we hope the features we are making available today will help inspire developers and provide a solid foundation for new applications to be built.

We are already excited to see developers who were helping us test the API deliver terrific applications. Today you'll start seeing the following sites and services integrate with Google Buzz:

End-users opt into using applications built with the Google Buzz API via an interstitial confirmation screen outlining the application's requested access scope (read-only, read/write, etc.). They can see which apps have access to their data and can disable access at any time from the Google Accounts page, the Google Dashboard, the “Buzz" tab in Gmail Settings, or from the app itself.

This initial iteration of the API includes support for fetching public per-user activity feeds, fetching authorized and authenticated per-user activity feeds (both what the user creates, and what they see), searching over public updates (by keyword, by author, and by location), posting new updates (including text, html, images, and more), posting comments, liking updates, retrieving and updating profiles and social graphs, and more. The best way to get started is to dive right in and begin reading the Google Buzz API developer documentation.

There’s a lot more to come, and we expect to keep moving quickly from here. But none of this would be possible without the hard work of everyone participating in creating the protocols upon which Google Buzz is built, so we ask and encourage developers to get involved with the communities behind ActivityStreams, OAuth, and the countless others that we depend on.

And as with any young API, there will undoubtedly be bugs and issues and places where we’ve deviated from what the specifications say, or with what developers may expect. When you see something amiss, get confused by an approach we’ve taken, or just want to comment on our progress, we invite you to update the Buzz API issue tracker and please join the conversation on the developer forum.

With that, we’d like to welcome everyone to the first version of the Google Buzz API. We can’t wait to see what else we can build together.

By DeWitt Clinton, Google Developer Team

Happy 5th Birthday Google Code!

How time flies! It was about five years ago that we launched Google Code to the world. When we launched Google Code, we wanted to make code.google.com a great resource where developers could learn about our vision for open source and the open web. We started in 2005 with a handful of our own open source projects, links to just eight APIs and an announcement of the first ever Google Summer of Code, our now-annual program that introduces university students to open source development. By 2006 our API list had grown to 21, in 2007 there were 37, and today our collection of more than 60 APIs receive over four billion hits per day. Check out the changing face of Google Code below -- from 2005, 2007 to the present.



With the meaning of open in mind, Google Code set out to foster best practices in developer documentation, build a community around web and open source development and demonstrate the power of Google technologies. Over the past five years code.google.com has come a long way from eight APIs, maturing into a destination for developers to explore our growing family of APIs and developer products, whether they speed up the web, alleviate cross-browser issues, make hosting web applications easy and scalable or make the web a more social place.

Google Code has also become an interactive place to share ideas. Not only can developers prototype their work in a Code Playground, they can also use Project Hosting on Google Code, a fast, reliable and easy way for developers to host all kinds of open source projects. Today, there are more than 240,000 projects registered, with commits coming in at about 17,000 per day...about 1 every 5 seconds. We also host 800 open source projects of our own, including four projects (Android, Chrome, Chrome OS and GWT) with over a million lines of code each.

It’s been an amazing five years, but there’s still a lot of work ahead. We’re dedicated to helping the developer and open source communities thrive in as many ways as we can. To celebrate our birthday and thank everyone for supporting code.google.com over the years we’re rolling out a new, faster Subversion server, which will double the source code storage for Project Hosting on Google Code from 1GB to 2GB. Happy coding!

By Chris DiBona, Open Source Programs Manager

Join the Conversation Around Google Buzz

This morning we announced Google Buzz, a new way to share updates, photos, videos and more, and start conversations about the things you find interesting.

We'd like to take this opportunity to invite developers to join us as we prepare the Google Buzz API for public launch. Our goal is to help create a more social web for everyone, so our plan for the Buzz API is a bit unconventional: we'd like to finalize this work out in the open, and we ask for your participation. By building the Google Buzz API exclusively around freely available and open protocols rather than by inventing new proprietary technologies, we believe that we can work together to build a foundation for generations of sites to come. We're ready to open the doors and share what we've been working on, and we'd like for you to join us in reaching this goal.

Please visit the Buzz API site on Google Code, subscribe to the Social Web Blog, and most importantly, join us on the Buzz API mailing list.

We'll have advanced sessions on Buzz APIs at Google I/O, our annual developer conference in May. To learn more about and register for I/O, visit code.google.com/io.

Update: Fixed typo in the first sentence.

By Brian Stoler, Tech Lead, Google Buzz

Another Round of Deprecation Policies for Labs Graduates

We recently published deprecation policies for a number of APIs that graduated from Google Code Labs. They state how long we'll support each version from when it's deprecated or a newer version is introduced. It will be 3 years for most, but the time period varies a bit from product to product.

• AdWords API terms
• AdSense API terms
• AJAX Feed API terms
• AJAX Language API terms
• AJAX Libraries API terms
• AJAX Search API terms
• Apps APIs terms
• Calendar Data API terms
• Chart API terms
• Health API terms
• Geo APIs terms (Earth API, Mapplets, Maps API, Maps API for Flash, and Static Maps API)
• Secure Data Connector terms

We still need to update the terms for a couple remaining graduates, but should have them all done within the next couple weeks.

By Neel Kshetramade, Google Developer Programs

Deprecation policies posted for 5 more APIs

We just posted updated terms of service for 5 more APIs to include transparent deprecation policies. This is part of their increased commitment as graduates of Google Code Labs. As we mentioned in March when we introduced Labs, each of these deprecation policies states that we'll support each version of the API for a guaranteed length of time from when it's deprecated or a newer version is introduced. While it's 3 years for most, it might be less for some. With this batch of updates, for example, the Checkout API has a policy of supporting old versions for 1 year while all of the others will support old versions for 3 years.

You can see the updated terms for all 5 APIs:

• App Engine terms
  
• Checkout API terms
  
• Documents List Data API terms
  
• SketchUp Ruby API terms
  
• YouTube APIs terms

By Neel Kshetramade, Google Developer Programs

YouTube <3's Developers

By Stephanie Liu, YouTube APIs and Tools Team

There's been a small flurry of announcements lately about things the YouTube APIs team has done to make life easier for our developers, and we wanted to make sure you heard about them!

Backwards compatibility guidelines
Since we just launched V2 of the API, we also published some guidelines and best practices to help ensure that breaking changes aren't introduced into your app with new versions. Read more in our "Mandate For Change" post.

Test your apps against new builds
A week before new builds are pushed to production, they'll go up on stage.gdata.youtube.com. Subscribe to our announcement forum to get notified about new builds, and do regression testing by pointing your app at stage.gdata.youtube.com. Read more in our "All the World's a Stage" post.

Interactive query generator
We released a helpful tool to play with API requests in the browser so you can get a feel for the mechanics. Because we show you the raw request and responses, it's also an easy way to do some quick testing and debugging. Read the full announcement in our "Try Before You Buy" post.

YouTube App Gallery
To help get you get some exposure and to help new developers get some inspiration, we launched the gallery. Browse, comment, and rate projects as well as submit your own. Read the full announcement here.

We hope this helps both new and old YouTube developers alike. Let us know how it's going in the discussion forum.

Introducing the Gears Geolocation API for all laptop WiFi users

By Charles Wiles, Product Manager, Google Mobile Team

I am thrilled to announce that today we have enhanced the Gears Geolocation API so that developers can now securely locate users to within 200m accuracy in major desktop browsers in hundreds of cities around the world. Whether your users are Chrome, Internet Explorer, Safari, Firefox or (soon) Opera users, you can now automatically deliver an experience that is tailored to their current location. For example, lastminute.com's new Radar application allows users to find nearby hotels, ITN's Google Earth mash up in Firefox allows users to see nearby news stories and Rummble's social discovery site allows users to automatically set their current location for friends to see.



When we originally proposed the Gears Geolocation API our goal was to make it easy for developers to deliver location enabled web sites on mobile phones. However we realized laptop users would benefit from location enabled web sites too. Today we are adding WiFi signals to the Geolocation API so that laptop users can benefit from location enabled web sites for the first time and mobile users from the increased accuracy. And because the Geolocation API is the same for developers in both desktop and mobile browsers you can even use the same code on both platforms!

In Chrome and Android, with Gears built in, you can deliver a location enabled web site without requiring your users to install a plug-in, but in other browsers they will need to go through a simple plug-in install process. We also submitted a simplified version of the Geolocation API as a WC3 specification and the upcoming Firefox 3.1 plans to support the W3C version directly. The Gears Geolocation API is completely free to developers and users through the default Google location provider.

To protect user privacy, the Gears Geolocation API server does not record user location. However, third party sites may do so, and we recommend that users only allow web sites they trust to access their location. Gears will always tell a user when your site wants to access their location for the first time and the user can either allow or deny your site permission. We recommend users check the privacy policy of your web site if they are in doubt as to how your site may use location information.

A new era for Book Search begins with new APIs

By Venu Vemula, Google Book Search Team

Since I joined Google, I've been working on Book Search, our project to help users discover what's inside all the world's books.

Today we are happy to include the developer community in this historic effort with the announcement of two new APIs:

• An Embedded Viewer API, which allows you to embed book previews on your site and control them programmatically using JavaScript.
• A robust Data API, which allows you to access full-text search results and access with users' book reviews, ratings, and individual My Library collections.
  

By allowing anyone to integrate with the complete Google Book Search index, we hope this broader community will find new ways to connect users with books that are interesting and relevant to them.

To learn more about the sites already using these APIs — including Books-A-Million, Worldcat, and GoodReads — check out our post on the Book Search Blog.

Or, if you want to dig right in, go straight to our newly revamped developer site.

Picasa Web Albums Enables Video Uploads Via API

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.

QR Codes now available on the Google Chart API

By Hiroyuki Komatsu, Google Chart API team

You can easily render 2D bar codes, known as QR Codes, with the Google Chart API, along with pie charts and bar graphs. If you haven't seen a QR Code before, you are looking at one on the right hand side (To see more, do an image search for "QR Code".)

QR Codes are a popular type of two-dimensional barcode. You can encode URLs, contact information, etc. into a black-and-white image like the one on the right. A QR-Code-enabled device can later scan the image and read back the original text. Learn more about QR Codes from Google Print Ads. If you don't have a reader Google also offers a QR Code decoder library: Zebra Crossing (ZXing).

This is how you can creating these with the Google Chart API:

Simply, there is a new chart type, qr, with attributes to tell the service what to produce:

cht=qr
chl=<text>
choe=<output>

<text> is text for the QR code. This must be url-encoded in UTF8. Note the space between hello and world is written as %20 in the following example.
<output> optionally specifies how the text is encoded into bytes in the QR Code. If this is not specified the default of UTF-8 is used. Available options are: Shift_JIS, UTF-8, or ISO-8859-1.

For the details, please read the full documentation.