Google APIs: A to Z

This guest post comes from Pamela Fox, a developer advocate at Google. Pamela has supported the Google Maps and Wave API communities, in addition to helping developers get started with other Google APIs.

One fateful summer 5 years ago, I discovered ProgrammableWeb and the joy of APIs. I spent my mornings coding on the Amazon, Flickr, and Google APIs, and spent weekends prepping entries for the API contests -- I actually made some good cash, student-wise, from those. At the same time, I was struggling to find a job that met my interests. I then discovered this "Developer Relations" department at Google, where I could spend my time teaching others how to use APIs, talking about them at conferences, and giving feedback to the API engineering teams. As someone who loves APIs and teaching, that sounded just perfect to me. So, about 8 months after getting my start with APIs, I began work at Google as the Google Maps API support engineer.

I've been at Google ever since and watched as we've released API after API -- challenging myself to try each one. We're at about 80 APIs now, and I shall have to concede defeat. Still, I've got a sense as to our API landscape, and that's what I've been talking to developers about lately, giving a talk called Google APIs: A-Z (embedded below).

There are many ways to try to categorize our APIs, so in trying to explain them, first, I divide our APIs into 3 separate types. There are HTTP APIs that you typically interact with from the server-side - like the RESTful Google data APIs, the RPC-based Geocoding API, and SOAP Adwords API. Then there are HTML/JS APIs that you use on the client-side - like the classic Google Maps API, and the newer Google Visualization and Chart APIs. Finally, there are Extension/App APIs to extend our products - like the original gadgets API, Chrome Extensions API, Google Talk bots, and Android SDK.

Almost always after I give a talk about APIs, developers ask "but why is Google offering this API?" We do offer many free APIs, and you guys want to know what's in it for us. Well, first there's the monetization reason: by offering APIs that make your websites better, more people use the web, which means more people click on Google ads, and we make more money which we can use to offer more APIs. Then there's branding awareness: every time someone sees a Google map embedded on a page, they see a Google logo, and subconsciously fall in love with us (or that's the theory :). Besides, we feel very strongly that users should have control over their data, and we've even created a team called The Data Liberation Front to help make that happen. By offering both user-friendly import/export options and developer-ready Google data APIs, we give our users the ability to copy their data into and out of Google in a number of ways.

So, after hearing about our APIs and why we offer them, you may still be asking yourself why you should use them. Depending on what you do, there are a few different reasons. First, you can use the extension APIs to reach Google users, like creating an Android App for their Marketplace, where you'll reach thousands of users who are actively searching for ways to enhance their phone experience. Second, you can use the Google data APIs to make your apps more compelling by letting users import from or export to various Google Apps. The Eye-fi card is a great example of this -- an SD card with a wireless microchip inside that automatically uploads to the photo website of your choice, like Picasa.

Similarly, you can use our HTML/JS APIs to enhance your website, sprinkling it with additional bits of functionality, like how the celebrity blog site embeds a Google translate widget to instantly appeal to a more global audience. We also offer several APIs that let you directly monetize your work. The most recent of these entries, the Google Apps Marketplace, lets you offer your business applications to Google Apps domains with whatever pricing model works for you (free, freemium, per user, etc), and all you need to do at the minimum is integrate Google single sign-on with your application. Generally, when you're using an API in your application, you are choosing to save money or time by outsourcing some piece of functionality or data to Google -- like deciding to use App Engine instead of building your own scalable infrastructure, or using a Google custom search box instead of writing your own search engine.

I've only really introduced a small portion of our APIs, and just a few different ways of thinking about them. To see the full gamut of the offerings, visit Google's directory for a complete list and to keep up to date with new APIs, subscribe to the Google code blog. Next time you're working on a product or a hobby project, think about what our APIs (or anyone else's) can do for you. Happy mashing!