All Feeds | XSL | RSS | Embed | Edit

Fall Housekeeping

When we introduced this blog over four years ago, the term AJAX was only a year old, and Google had exactly one relevant API . Ajax has since become a mainstream part of the Web, and our family of APIs has grown. Like many growing families, we’ve accumulated a lot of cruft over the years, and have outgrown our first home. Time for some housekeeping.

API Documentation - Now easier to find and use
We’ve reorganized our documentation to make it easier to find what you’re looking for, based on what you want to do. We used to group our APIs based on technology - for instance, there were Google Data APIs and AJAX APIs. Now, you’ll see that each API has been given its own place, including its own documentation pages. This new documentation has been created from the ground up to provide a better experience for people coding against the APIs. We’ve also organized these more logically by product, such as moving the Book Search API into the Books family of APIs, and added many more samples to help you get started.

A fond farewell
In the spirit of consolidation, we’ll be retiring this blog in favor of the Google Code Blog. By concentrating on fewer blogs, we’ll be able to keep the blog fresher and help make sure that as wide an audience as possible is able to benefit from our posts. We’ll continue using tags, so that you can subscribe to your favorite APIs and focus on the content that most interests you (though we hope you’ll check in occasionally to see what new stuff you might be missing).

Show your support for the Code blog by hopping over to read about the new Google APIs console and Custom Search API, and also say good-bye to the Web and Local Search APIs, which are being deprecated. Full post here.

Posted by: Adam Feldman, Product Manager

Increase site efficiency by retrieving just your preferred number of results

When using any of the searchers available in the Search API, four results are returned by default. Historically, it has been possible to request a large set of eight results (or ten for filter Custom Search Engines), but that’s it. We understand that there are many use cases for this API, and some of them require a finer grain of control over the number of results displayed.

For instance, with the JavaScript API, you can use .setResultSetSize(1) or .setResultSetSize(6) in addition to using the enum to request a SMALL_RESULTSET or LARGE_RESULTSET. When using the RESTful interface, you can also use any integer from 1 to 8 with the rsz parameter.

With this addition, you can now request an arbitrary number of results, based on the exact number you need. By requesting only the results you’re going to show to the end-user, you can make your site or app more efficient. Also, this will control the cursor values that can be used to retrieve subsequent pages of results (and impact paging in the Custom Search element).

For more details, check out the documentation, and if you have any questions, stop by our IRC channel and support forum.

Diacritization added to the Google Language API

Earlier this year, we launched the Tashkeel (Diacritization) service on Google Labs. I'm pleased to announce that we've added an experimental Diacritization component to the Google Language API. This is a simple JSON API which you can use to add diacritic symbols to strings of Arabic text.

To test it out, try clicking this link:مرحبا%20العالم&last_letter=false&callback=result

A URL-encoded string is supplied as the message parameter, and it's returned by the API with diacritics included. These symbols are useful to people just learning the language and as an important pre-step for several text processing applications.

Right now, the API only supports Arabic, but we're working on adding more languages, as well as a JavaScript API, so be sure to watch this blog for details. For more information, see the documentation and our post on the Google Arabia blog (you may want to click "view post in English").

Posted by: Adam Feldman, Product Manager and Jeff Scudder, Software Engineer

Google Feed API — Now with instant gratification

One of Google's most popular APIs is our Feed API. This API is found all over the web, making any feed content available for developers to embed on their sites.

A problem with embedding content in this manner is that there's no good way to make sure that your visitors see the freshest data, regardless of how long they stay on your page. Of course, you could try polling (also known as the "are we there yet?" method), repeatedly reloading the feed to see if the content has changed. This technique is generally a waste of bandwidth and doesn't always result in very low latency.

Instead, we've got something better. I'm pleased to announce a preview of a brand new version of the Feed API, which includes push updates. With this new version, you'll be able to make the latest feed data available to your visitors - when it's available - without polling or requiring a page refresh. The best part is that this will work with any PubSubHubbub enabled feed.

Here's a short demonstration of what I'm talking about:

Each element is designed to help you get started quickly without spending time on the deep technical details. Yet behind it all, Google Web Elements are powered by Google's scalable and flexible developer APIs, offering a world of customization just beneath the surface, keeping up with your site as it grows.

For more details, check out the Google Code and Custom Search blogs. Google Web Elements are already available for eight of our most popular products, with more soon to follow. To get started, visit the Google Web Elements homepage and please be sure to let us know what you'd like to see us work on next.

Want to know what else is going on at Google I/O? Follow us on twitter @googleio and twazzup.

AJAX APIs Playground Ver. 2

I am very pleased to announce version 2 of the AJAX APIs Playground. For those of you not familiar with it, the Playground is an educational application designed to show interactive code samples for some of Google's coolest Javascript APIs. Of the new changes, the most obvious is the sweet new UI, thanks to help from Roman Nurik of the Google Earth team.

The new features are:
* Break points (simulated in Javascript)
* Firebug Lite in output for debugging
* Line numbers in code editor
* Ability to edit HTML of samples

The breakpoints and Firebug Lite additions are my favorite new features. But why did I include Firebug Lite when all web developers (should!) have Firebug installed? Because when code runs on the Playground, it runs in an iFrame. That iFrame does not have the Firebug object initialized in it. Since it is a cross-domain iFrame, there's no simple way to add Firebug to the iFrame's window object, so adding Firebug Lite was the best approach. This makes it so you can now use all of your favorite Firebug debugging convenience functions in the Playground!

To use Firebug Lite and breakpoints, simply click on the line number you want to add a breakpoint to and hit "Debug Code". This will insert Firebug Lite into the output and pause the execution on the breakpoint line number until you to click the play button to continue. Try adding a breakpoint to a line, clicking "Debug Code", then opening Firebug Lite and typing in a variable name to inspect the contents/value of the variable at that point in the code.

Adding breakpoints and forcing Firebug into a local function context were really fun engineering problems, so if you want to check them out (or contribute code to the Playground) go to the open source repository for it, come chat it up on IRC, or talk with me in person at the quickly approaching Google I/O conference (early bird registration runs until May 1).

Also, it's really important that you share your feedback so that I know what you'd like to see in the next version of the Playground! Thanks, and enjoy the Playground!

Making content creation easy with the Google AJAX APIs - Guest post

We started with the idea that we could make it significantly easier and more fun to discover new and interesting things to do anywhere in the world, based on recommendations from people who know a place well. Whether it was a neat museum, a hidden local restaurant, or a great place to go shopping we wanted to make it super easy and fun for people to share recommendations for their favorite places, wherever they might live.

The trick of course was in how to do this. It was important for us to combine ease of making a recommendation -- our goal was that it should be as simple as entering the name of a place, and a few sentences about why you liked it -- with rich information about a place so it was really useful to others -- photos, contact information, maps, etc. The solution, not surprisingly since I'm writing here, was to use a number of Google's APIs to gather related information about the recommendation and make it easy for our members to include it in their recommendation.

You can best see how this works by going through our recommendation flow, or watching the video below.

Let me walk you through how this is working under the hood:

1) When the page loads, the first thing we do is use the Google loader to load the JQuery and JQuery UI libraries, as well as Google Maps. As part of this, we also grab the user's current location using google.loader.ClientLocation and store the lat/lng if available to use later.

2) In step 1, we ask the user for what's being recommended. We use this string to do a Google local search for business listings and KML results that match, using the user's current location to bound the local search by setting the sll and sspn parameters. Between local business listings and KML results, we can offer incredible global coverage of everything from restaurants to tourist attractions to hole-in-the-wall bars and clubs. We're using the JSON version of the local search API, which we call from our servers using Python's urlopen() so that we can supplement the results with our own database of results.

3) In step 2 we do an image search for related images using Google's image search API. While we let users change the search terms to find just the right picture, often our default image search (which combines the name of the place and a city name) returns great results. There are photos of almost everything, so you can even recommend a particular dish at a restaurant in Taipei and have the photos to go along with it.

4) In step 3, we ask for a few sentences about why that place or activity really stands out to them. After the recommendation has been submitted, we use the Google Language APIs to detect the language of the recommendation, which we can later use to filter content by your language, and we hope to someday integrate the ability to translate recommendations into your language of choice.

Its a very simple and fast process for the user making the recommendation, but the result is a recommendation with address, phone number, map, and photo that is really useful to another user looking to discover something new.

We've built our whole product around the Google APIs, and feel like we're just scratching the surface of what's possible. We're planning to let users add other information (like related websites, searches, news, etc.) using Google's APIs as well.

We'll be at Google I/O on May 27-28 talking about what we've done so far, and will hopefully have a few new uses of the Google APIs to show off at that time. Please come say hello -- we'd love to hear your feedback on nextstop, or share tips on using the Google APIs. You can also check out some of the places recommended near the Moscone center, or add a few of your own!

Carl Sjogreen (co-founder,

Updated Local Search Control used in brand new GoogleBar

A much requested feature, the Local Search Control now includes ads when a search is performed. Users will benefit from seeing targeted and relevant sponsored results, and you can benefit by sharing in the revenue of including these results on your site. Ads aren't the only thing that's new - there's also a new (and, we hope you agree, better) UI:

This new Local Search Control has been used in a brand new version of the GoogleBar (part of the Maps API). In almost all cases, the GoogleBar provides the ideal way to add searches to Google Maps. The GoogleBar, too, includes advertisements with the results. In order to share in the revenue, you need to supply your AdSense publisher ID. You can use your existing ID or sign up for a new AdSense account. Once you have an account, get your AdSense publisher ID and include it as an option when you set up the GoogleBar:

<script src="/jsapi?key=YOUR_KEY_HERE" type="text/javascript"></script>
<script type="text/javascript">
google.load("maps", "2");
var opts = {

googleBarOptions : {
style : 'new', // This tag is necessary for the first few weeks until the new UI becomes default
adsOptions : {
client : #### // Your Google AdSense publisher ID
map = new GMap2(document.getElementById("map"), opts);
map.setCenter(new GLatLng(33.956461,-118.396225), 13);

Optionally, you may also specify an AdSense for Search channel (more info on channels), the Ad Safety Level to associate with your advertising, and the language in which to display results. For a full list of options and details on including them, see the GoogleBar documentation. Note: currently ads only appear for results that are inline - this limitation should be removed within a few weeks.

If you'd like to learn more about the new underlying, low-level Local Search Control, the reference documentation and Code Playground examples contain everything you need to know.

For more information, see this recent post on the Maps API blog. Questions or comments? Please visit the AJAX API and Maps API discussion groups.