The Google Developer Day 2007 took place in 10 cities spanning the globe beginning in Sydney, Australia and ending in Mountain View, California. This is a report on some of the sessions at the event in Hamburg, Germany, on May 31, 2007.
In the opening keynote Karl Krainer, head of marketing Northern Europe for Google, introduced the speakers of the event and presented the schedule. He also welcomed Stephan Uhrenbacher, founder of Qype. Stephan talked about his experience with the Google Maps API and its impact on Qype. Qype is a platform for ranking service providers, shops, restaurants and all other public locations or providers in germany. Google Maps is a key technology in this platform as it provides geographic data for all locations and shows other (related) locations within a certain range of the location in question. Rankings are associated with the Qype users who issued them, making Qype a socializing platform as well. Asked what features he wishes for Google Maps or any other Google API, he answered that he is really interested in a localization feature, i.e. that for instance Google Ads could be constrained to provide items matching a certain location.
Douwe Osinga, an Engineer with Google Swiss, talked about the Google Gadgets API. Google Gadgets are mini applications (applets) that are implemented as XML documents. Google provides free hosting of Gadgets as well as a gadget directory. The Gadget XML document may incorporate JavaScript code, allowing the application to perform a great variety of actions, e.g. using the Google Data APIs. Consisting of XML and JavaScript Gadgets may run almost anywhere and can be readily distributed within weblogs and web site, thereby gaining a lot of traffic quickly. The anatomy of a gadget is very simple: the root document node is a "module" containing a "moduleprefs" element, "userpref" elements, and "content". Gadgets provide several interesting features, e.g.:
- Fetching remote content - fetch and manipulate remote textual (typically HTML), XML, and RSS/Atom feed data.
- Internationalization - any text within the gadget can be put into message bundles. At runtime Google fetches the right bundle corresponding to the language settings of the local browser.
- Caching external resources - Google provides caching for any external resources used by a gadget.
Frank Mantek, working for Google Germany, talked about the Google Data APIs Protocol (GData). He began his talk by arguing why Google chose to provide a REST based API. In the past Google based their APIs on SOAP and developers had to cope with a "bunch of APIs and specs" differing from product to product. Now Google provides a unified API for their services consisting of a set of four operations, URIs and Atom/RSS feeds. According to Frank Mantek this set of tools has been proven to work, simplifies development, and is sufficient for most use cases (> 80%). There might be some requirements that call for sophisticated APIs, e.g. transactions, message-level security or notification-reply message exchange patterns, but those are the minority. Currently GData can be used to access data from the following Google services:
- Google Apps Provisioning
- Google Base
- Blogger
- Google Calendar
- Google Code Search
- Google Notebook
- Google Spreadsheets
- Picasa Web Albums
Frank quoted Dare Obasanjo on GData in order to support his arguments for the REST based approach in comparison to a SOAP alternative:
Contrast this with the API efforts on Yahoo! Developer Network or Windows Live Dev which are an inconsistent glop of incompatible RESTful protocols, SOAP APIs and XML-RPC methods all under the same roof. In the Google case, an app that can read and write data to Blogger can also do so to Google Calendar or Picasa Web Albums with minimal changes. This is not the case when using APIs provided by two Yahoo! services (e.g. Flickr and del.icio.us) or two Windows Live services (e.g. Live Search and Windows Live Spaces) which use completely different protocols, object models and authentication mechanisms even though provided by the same vendor.
GData generally supports CRUD operations via the HTTP verbs GET, PUT, POST, and DELETE on resources, represented by URIs. The results of these operations are provided as a syndication feed (Atom/RSS). The Atom metadata have been extended by additional tags in order to fulfill the needs of the individual Google services. Queries and support for optimistic concurrency have also been added. Optimistic concurrency has been implemented by "edit links". Every link (URI) to a resource includes a version info. This version info is automatically altered with every update. Concurrency issues are checked by comparing the submitted version info with the one on the server during every update or delete.
Authentication is implemented by Google Desktop or Web Authentication Service. Both services create an authentication token, which might be used by the client application to authenticate individual users. The Web Authentication Service is invoked via a redirect to the corresponding Google Site. In either case the password remains secure.
The talk covered some examples of what other developers are doing with the Google Data APIs:
Frank also mentioned some weaknesses of the Google Data API Protocol, which will be addressed by Google in future versions:
- Authentication - The Web Authentication Service is invoked via a redirect, which "kicks" the user off the client app and takes him to a probably completely different looking UI. Many customers have complained about this.
- Optimistic Concurrency - Edit links aren't a clean solution. Frank said that they should have used strong ETags instead.
- Incremental changes/updates - There is currently no way to do incremental updates, i.e. to change a certain part of the resource without sending a complete new version.
- Versioning - That's an open issue. Google hasn't decided on how they will version the Google Data APIs, though this will most certainly be accomplished by a set of new URIs. Old version might be put offline after a certain period.
Matthias Zenger, Tech Lead Manager with Google Swiss, talked about Google Base, which provides a platform for applications dealing with structured data. Anyone can define item types and post items to base in order to provide a base of structured data, which might be found and appropriately presented by Google Search.
The Google Base data model is very simple. Base is a repository of data items, whose structure is defined by item types. An item type consists of a set of typed attributes, which represent name/value bindings. "Product" is an example of an item type. This item type is used by Google Product Search (the successor of Froogle).
Google Base is based on GData and adds some specific extensions. All CRUD operations are supported for creating, reading, updating, and deleting items. It also incorporates structured queries via the "bq" query parameter, e.g. "?bq=[cuisine: asian][cooking time <= 45 minutes]". The Google Base Query language offers standard queries adhering to the "[name(type) op value]" pattern, specialized date and location queries, a build-in and custom ranking functions (sophisticated SQL "order"), and crowding expressions (SQL "group").
Matthias closed his session by demonstrating one of the example projects using Google Base: Honda Certified Used Cars.
The attendees of the Google Developer Day were able to get an in-depth look at the latest Google services, their development and usage. The sessions have provided a wealth of information and there were plenty of opportunities for networking and discussions with the developers. The GDD07de homepage provides streaming live sessions for those who haven't had the chance to attend the event.