Launched: Google Health PHP Client Library

Thursday, December 11, 2008 at 2:57 PM



Here's good news for all you PHP developers working with the Health Data API!

The Google Data PHP Client Library now includes support for the Google Health Data API. You can download the latest copy from the googlehealthsamples project page.

In addition to the download, we also have a few developer resources to get you started:
Getting Started with the PHP Client Library
PHP Developer's Guide
Sample Application

Google Base API Now in the JavaScript Client Library

Wednesday, December 10, 2008 at 8:41 AM



Today, we launched a new version of the JavaScript client library that includes the Google Base Data API.

The Base API is great for creating interesting JS mashups. With this new release, it's much easier to build gadgets, mashups and JS applications that reuse the content in Base. In addition, you can interact with your personal items feed to create, modify and delete existing items.

To get you started, we've published a new Interactive JavaScript Developer's Guide and created two samples that demonstrate the library's capabilities:

Base Items Mapper

A read-write mashup that lets users update their geocoded Base items using the Google Maps API.

Jobs Finder from Google Base
An iGoogle gadget that returns a list of nearby jobs. The listings are catered to the user's search preferences.

No, You Lock It Up!

Wednesday, December 03, 2008 at 3:19 PM



The latest realease of the Google Data Python client library (v1.2.3) includes the usual updates and bug fixes, but also adds two important features, OAuth and secure AuthSub. Both authorization mechanisms allow developers to make their web applications more secure by requiring API requests be digitally signed. Check out the sample applications to get started:

Secure AuthSub example using the Google Health Data API
http://code.google.com/p/gdata-python-client/source/browse/trunk/samples/authsub/secure_authsub.py




OAuth example using the Google Documents List Data API
http://code.google.com/p/gdata-python-client/source/browse/trunk/samples/oauth/oauth_example.py



You can download the latest client from the client's project page. As always, if you're interested in contributing, the door is always open. Drop by the contributors discussion group and jump right in.

Like a Version; AtomPub Compliant for the Very First Time

Wednesday, November 19, 2008 at 12:53 PM



Since the Atom Publishing Protocol specification was finalized, we have been working on making the Google Data APIs compliant with the AtomPub standard. As of today, we are releasing a new version of most of our services that achieves full compliancy with RFC 5023.

If you're worried that this may break your current application, rest easy. This change will only be available in API version 2 and higher. If you are happy with the current version, you can keep doing what you've been doing and the API will continue to work as it always has. If instead you'd like to use the AtomPub compliant version (and the new v2 features), just specify API version 2 in an HTTP header, and you're good to go.

One of the new v2 features is the use of HTTP ETags for optimistic concurrency. ETags are a web standard that work well with HTTP caching. The client libraries that support version 2 will handle ETags automatically, but if you are interested in how ETags look at the protocol level, check out the details in the Google Data Protocol Documentation. Some services are using V2 to introduce additional improvements as well (for example, YouTube's new geo-search feature), so be sure to check out the documentation for your favorite service to see what's new.

For those of you who'd like to try out version 2 in our client libraries, the Java and .NET client libraries have been updated with V2 support. To see a list of the services who are V2 compliant and to find out how to migrate your apps to the new version, check out our migration guide. We recommend migrating to v2 if you can, as any future improvements will be introduced to version 2 and higher. For further information about the release, please check out the new Google Data documentation or head over to our discussion group.

Updated 11/20/2008 to correct RFC number

Federated Login For Google Account Users

Tuesday, October 28, 2008 at 4:10 PM




*Due to the strong interest from our developer community and the high registration rate, we decided to make it easier for websites to experience the new API and removed the registration requirement. For more information see the OpenID post on the Google Code blog.


Many of the developers who use the Google Data APIs have asked for a way to remove the need for a login system on their site. Today we announced that we are allowing websites to test an API that will permit single sign-on for Google Account users who visit your websites. The initial version of the API will enable websites to validate the identity of a Google Account user including the optional ability to request the user's e-mail address. Here are screenshots of the example flow that a user might see if he or she starts at a website that uses this new feature.

The user would open the homepage of a website that uses the Google Data APIs (KidMallPics, in this example), and instead of having to fill out a login box or account creation form, he or she would simply click the Google button.


The user would then be taken to the Google website, where they would confirm they want to sign in to KidMallPics.


Finally, the user would be sent back to the KidMallPics site, where he or she would be signed in. If the user had previously signed into KidMallPics and authorized them to access the user's photo account at Google, then the user could now perform actions on the KidMallPics website such as having his or her mall photos transferred to Google using the Google Data protocol.


This new API is already being used by www.buxfer.com and www.plaxo.com. Shashank Pandit at Buxfer says that "We now offer all our users the ability to login to Buxfer using their Google Account to avoid the need to create yet another login and password." Joseph Smarr, Chief Platform Architect at Plaxo says, "It's great to see Google become an Open ID provider in addition to supporting OAuth, which we already use. We are thrilled to be among the first sites to allow users to login with their Google Accounts. This is going to be great for users, Plaxo and the web."

We chose OpenID as the protocol for our identity provider because it makes a large set of open source implementations available for many different development platforms used by Google Data API developers. To learn more about this new API see http://code.google.com/apis/accounts/docs/OpenID.html.

Google is also working with the open source community on ways to combine the OAuth and OpenID protocol so a website can not only request the user's identity and e-mail address, but can at the same time request access to information available via OAuth-enabled APIs such as Google Data APIs as well as standard data formats such as Portable Contacts and OpenSocial REST APIs. In the future, this should allow a website to immediately provide a much more streamlined, personalized and socially relevant experience for users when they log in to trusted websites.

Updated 10/30/2008 to reflect changes to registration process

An Introduction to REST

Monday, October 27, 2008 at 5:40 PM



Google Data APIs are based on the Atom Publishing Protocol and both Google Data APIs and AtomPub get many advantages from being RESTful protocols. Often the meaning of REST and the advantages of RESTfulness go unexplained so I put together this short 15 minute video that explains REST and some of the advantages you get with a protocol built in that style.


* For higher quality, click through to YouTube.com and select the "watch in high quality" option.

Update, Share, File: Documents List API launches new features!

Thursday, October 23, 2008 at 10:47 PM



I am very happy to announce that three major features requests have been implemented in the Documents List Data API this week. These are:

  • Update document content: You can now issue PUT requests to your documents and modify contents, metadata or both. (Issue 277)
  • Share by programmatically controlling ownership: There is now an ACL feed for each document that you can modify by adding or removing entries. (Issue 311)
  • File your documents: You can now create new folders in the API, move documents in and out of folders and have full access to nested folders. (Issue 377, Issue 383)

Please check out the updated documentation and look for these features being implemented in our client libraries soon.