There's this hilarious scene in "Moscow on the Hudson," where Vladimir (Russian defector played by Robin Williams) goes to the grocey store to buy coffee . . . and begins to hyperventilate because he's overwhelmed by the staggering number of brands available to him.
That's also a good representation of what I felt like when trying to figure out which APIs I should use in my first Google Mashup Editor experiment! Fortunately, I've been able to make some decisions to narrow that scope considerably. I decided to limit my first mashup experiment to only Google provided feeds/API's. I know, that seems kind of arbitrary, but when you think about it, the most likely feeds/API's to have problems with the Google Mashup Editor are the ones NOT created by Google. So by limiting it to Google products initially, I should have a better chance of succeeding.
So, I've been reading up on the various Google Data APIs-- and there are probably well over a dozen of those! You've got the Blogger Data API, which lets you read/create/update/delete entries in your Blogger powereed blog. You've got the Google Docs Data API, which allows you to list the various documents you have in your collection of online documents. You've got a Google Spreadsheet API which allows you to read data from a specific spreadsheet. It's still quite a lot to absorb.
But the one that blows my mind the most is Google Base and its associated APIs. Basically, Google lets you create a database (except its all in XML instead of tables, rows and columns) and then use that database as the backend for your web application. The data is public, so you wouldn't want to put any confidential info in it, but if you are building a web app, chances are you are trying to make that data as public as possible anyway, right? Otherwise you would be running it on an Intranet server or internal file server. (Yes, I know, some people have no damn sense, so I shouldn't assume that.)
The potential of Google Base is enormous. I just need time to wrap my brain around the whole new paradigm-- to stop thinking in terms of relational database tables, and start thinking in terms of XML items that can have one or more possible values for the same attribute built into each item.
So, assuming I can figure out Google Base-- what other APIs should I mash it up with? The obvious/too easy choice is Google Maps. Google Base features a "location" type, so I could use it in conjunction with Google Maps to track locations of some type or other. But, how incredibly lame and unimaginative is that? I mean, everyone and their brother has already done that-- so unless I decide to track something really offbeat, like Elvis sightings or crop circles, no one else is going to find it useful or interesting. And let's face it, Elvis and crop circles are novelty items at best.
The goal here is to come up with a-- an-- "alloy" of two services that no one has really considered combining, and winding up with something greater than just the sum of the two original parts. Like maybe Google Base with a bunch of data about the various incarnations of Linux distributions and their ancestor/decendent relationships, combined with Google Charts to provide some kind of visual "family tree."
Sigh. Yeah, I know-- no one besides hard core Linux geeks would care. And maybe not even most of them. But it's an example of the sort of ground breaking thought process that needs to go into a mashup.