Table of Contents
In the previous chapters, we focused on creating mashups through combining a number of technologies: XML, PHP, JavaScript, Python, and so on. As you’ve seen, creating mashups takes some amount of skill and knowledge. Can specialized tools make it easier to create mashups? In this chapter, I’ll introduce several mashup-making tools and show the basics of how to use a few of them. My goal in this chapter is to pick ones that are popular, useful, and illustrative of some important issues or trends.
The focus of this chapter will be on using the Google Mashup Editor (GME) (in conjunction with Yahoo! Pipes) to build a Flickr/Google Maps mashup; it’s like the one you saw in Chapter 10, but this one will show you how mashup-making tools make it easier (or different) from straight-up PHP and JavaScript programming, which you saw in Chapter 10. Specifically, this chapter includes the following:
A tutorial on the GME
A way of comparing mashup-making tools with the straight-up programming you did in previous chapters
I’ll briefly describe some other tools (Microsoft Popfly, Dapper, and others). By essentially re-creating the Flickr/Google Maps mashup using the GME and Yahoo! Pipes, you’ll see what mashup tools get you and what they don’t get you.
With a mashup-oriented mind-set in which you prize being able to integrate data and services (because integration brings value), you care about how to introduce new things that can be well integrated with the stuff you already use, without a high cost (in learning or effort to make those bridges).
Currently, creating mashups takes a lot of work to knit APIs together. You’ve already seen that work in the previous chapters and will see it again in the chapters that follow. APIs are similar to one another, but they are all somewhat different. One day, perhaps, you’ll be able to mash up different APIs the same way that you can surf from one web site to another and make sense of them all. It may never be that easy, but it should be easier than how it is today.
Case in point: although WSDL is not perfect, something like WADL (roughly WSDL for RESTful APIs) would be really helpful in alleviating the syntactic complications of connecting stuff, if not exactly making autosemantic connections possible.
Another major problem is that getting data to work together from different APIs requires translating among them. RDF promises to be a close-to-universal data representation. I have always thought there is some merit to the semantic web stack, at the bottom of which is RDF. Hence, I’m keeping an eye on RDF and other semantic web tools. I can certainly believe that if more and more data were expressed in RDF, things would connect better. RDF is, however, not a panacea. (That’s why I think a study of the SIMILE project (http://simile.mit.edu) is a practical way to start looking at semantic web technology.)
Specifically, when you use a new API, you want to minimize the type of new learning; you want the API to be similar to what you’ve already seen before. I think of the DRY (“don’t repeat yourself”) principle: it’s nice to not have to tackle the same thing repeatedly—solve it once, run it anywhere. For example, if you write code to access the Flickr API in one language and in one framework, wouldn’t it be nice to be able to not have to redo that code when you have another need? That’s the ideal anyway.
Tools and services can help you reach these goals. The key aspect of good tools is that they simplify the routine stuff and let you concentrate on the essence of the problem. There are always trade-offs, however—and we’ll look at them as we look at the various tools.