Although possible, it is unlikely in today's web application environment that you will only provide data inside your own application. Chances are high that you will include data from other sources as well. This means you have to implement strategies so that your application will not suffer from downtime of other applications. Though you are dependent on other data, you should make sure your actual live system is not, or at least it has the capability to function without the data provided.

The first recipe will show a practical example of integrating an API into your application. It will use the nice Google Chart API. In order to draw such graphs, the templating system will be extended with several new tags.

Another quick example will show you how to include a Twitter search in your own page, where you have to deal with problems other than the one with the chart API example.

The last two examples provide some tips on what to do when you are being a data provider yourself, and how to expose an API to the outside world.

However, first, we should dig a little deeper into the basics of mashups.

If you are asking yourself what mashups are, but you have already built several web applications, then chances are high that you have already created mashups without knowing it. Wikipedia has a very nice and short definition about it:

See http://en.wikipedia.org/wiki/Mashup_(web_application_hybrid).

So, as seen earlier, just by putting Google maps on your page to show the exact address of some data you stored, you basically created a mashup, or maybe you have already included a Flickr search on your page?

What you create out of mashups is basically left to your power of imagination. If you need some hints on what kind of cool APIs exist, then you may go to http://www.programmableweb.com/ and check their API listings.

You can distinguish between the two types of mashups, namely, those happening on the server side, and those happening on the client side.

You can render a special link or HTML snippet, which resembles a Google map view of your house on your home page. This is client side because the data fetching is done by the client. The only thing you are providing is the link that has to be fetched.

In contrast to this, there might be services where you have to query the service first and then present the data to the client. However, you are getting the data from the API to your application, and then using it to render a view to the client. A classic example of this might be the access to your CRM system. For example you might need to get leads or finished deals of the last 24 hours from your CRM system. However, you do not want to expose this data directly to the client, as it needs to be anonymized first, before a graphical representation is shown to the client.

The most important thing is to ensure that your application still works when the data provider is down. It should not run into timeouts, blocking your application on the client side as well as on the server side. If you keep fetching the same data, then you might want to store it locally in order to be independent of outages. If you really rely on this data, then make sure you have SLAs on your business, and a failure-proof implementation that monitors outages and keeps on trying to access the data end point.