Graphic, schematic maps can very useful in a wide range of charting scenarios and thanks to a recent upgrade, now you can use the Google Chart API to create them. As we reported earlier, Google’s Chart API is one of the simplest of all Google APIs. By passing parameters in the URL (i.e., HTTP GET), you can get images for various types of charts — bar charts, pie charts, line charts, etc — that you can embed on any web page. Plenty of mashups are already using the API including the 15+ mashups listed here.
The recent update adds this fun and useful capability as you can see in the docs. You can embed static maps that you can color by country or by US state. Here are a few simple examples of such maps, starting with a world map:
http://chart.apis.google.com/chart?cht=t&chs=440×220&chd=s:_&chtm=world
You’ll note that the parameters in the URL control the map, three of which are mandatory for any Google chart:
Compare the world map to the “Hello World” of Google Charts to see how the same API can be used to simple pie chart (click on the pie chart to see the full url/call):
Going back to the world map, see how changing the chtm parameter in the URL displays a map of Europe and using three additional parameters (chco, chld, and chd) highlight Hungary in green, while keeping other European countries an off-white:
Are people already using the Google Chart API to make maps? Take a look at the article Making maps with Google Chart API (listed in the ProgrammableWeb mashup database), which discusses the issues involved with generating the following fuller example of a world map:
Jeffrey Barke wrote a short tutorial for creating maps with the Google Chart API.
As others have noted, the maps one can create in this way are more demonstrations of what’s possible than fully developed functionality — so it’ll be interesting to see whether/how Google refines this feature of the Google Chart API.
For more on the Google Chart API at ProgrammableWeb check-out Google Chart Mashups: Love and Stats.
If you want to write mashups in Java these libraries might save you a lot of time. Just as with the 12 Ruby Resources we looked at last week, these resources can greatly simplify access to major APIs. Some are officially supported by the API providers themselves and others are independent, open source efforts.
Read the rest of “7 Java Resources for Mashups” »
Want to build a mashup using Ruby? To help you get started we’ve rounded-up a dozen Ruby libraries for open web APIs that can help you get a head start. Most of these are Ruby wrappers — often as gems — that simplify coding for specific APIs and sometimes across APIs.
Read the rest of “12 Ruby Mashup Resources” »
As part of a new ongoing ProgrammableWeb feature, we’ll start providing a regular stream of links on a variety of API, mashup, tool and industry topics. Rather than group them just as ‘links’, these will be posted in a unified theme. So today’s are coding-centric. (Keep in mind, there are now over 60 how-to mashup and API articles indexed on our /howto page).
Read the rest of “Mashup Coding Links: Google, Security, REST” »
Continuing the series on books for mashup developers — last week Flickr Mashup Books — here is a quick summary of books that can help you build mashups with the various Amazon APIs.
Note that the Amazon APIs are quite popular with 94 Amazon e-commerce API mashups listed at ProgrammableWeb. And you can use the Other Amazon APIs link on the left navigation of that page to see the 10 other Amazon APIs.
Want to learn how to code your own mashups? Try reading a book. There’s a growing library of books available now that are either fully or partially dedicated to programming mashups. I’ll start a series of posts on these books starting with a few for the Flickr API:
Ryan Campbell over at Particletree wrote this nice introduction on How to Add an API to your Web Service. Good for beginning without too many assumptions about what you do or don’t know about things like REST or SOAP. He outlines many of the decisions you’ll have to make including data format support and error handling. See also some of the links in his Required Reading section for more.
Mike Pegg does a great job tracking the most interesting maps mashups over at his Google Maps Mania. Occasionally he also does a roundup of tools for creating or enhancing Google Maps. Follow this link to see his eighth roundup of these tools along with links to the previous seven roundups. Good mix of Google Maps-focused tools.
ProgrammableWeb has a popular howto page that covers resources for a variety of APIs.
Alex Bosworth over at Source Labs (and creator of the great open source resource SWiK) writes consistently good posts and Monday’s was no exception: How to Provide a Web API. In it he addresses the question of “What are a few simple rules for providing a web API?” with these five points:
I completely agree with that list and might also add: a) provide examples, and b) document and support it. Neither of these need to be super extensive/expensive, just enough to get things kick-started (docs/examples) and help support the developer community as it grows.
This reminds me of Nat Torkington’s excellent post awhile back on How To Roll Out An Open API. He makes a good case that providers should: Make signup simple, offer toolkits for the languages that Internet developers use, and think laterally about business models. Recommended reading.
Duane Merrill over at IBM’s Developerworks just posted this good introductory overview Mashups: The new breed of Web app. He covers the various genres (as classified by tag here), the technologies including REST/SOAP, Ajax, RSS, RDF and screen scraping. And perhaps the most interesting part, the “Technical Challenges” section that looks at issues in data integration, data quality, and component model issues. There’s also a social challenges section with a quick look at licensing and commercialization issues.
Nicholas Carr followed-up on some of these issues in his post Bastard apps. He makes good points about data quality, reliability and consistency issues in what he calls Web 2.0’s truthiness problem.