With all the exciting talk on mashups, it's important to realize that, as with any new technology and way of programming, the road is usually fraught with dangers. Rightly the map around mashups should have bright neon lights flashing 'Here Be Dragons'. Here are some possible problems (but not all) you might face when developing web mashups:
Unreliable external APIs
Commercial dependency on third party data and services
Losing your users to external source providers
One of the most common complaints you will encounter as you develop web mashups is that you are highly, if not totally, dependent of the reliability of the mashup APIs you use. The two critical aspects of a web application—availability and response time—are not under your control, especially from sources that are provided freely to you.
Unfortunately at this point in time there is no viable way of resolving this completely. The only way of ensuring full availability and response time that meets your own requirements is to not have external dependencies at all. This is not possible of course, because web mashups are all about using external data and services.
However there are a number of ways to work around this issue:
Do not use mashups for mission-critical services. If the service is mission critical for you or your user, don't use mashups or at least not those that fail to guarantee certain availability and response time.
Have an agreement (normally commercial) with your external mashup API provider that provides back-to-back service agreements with your own services. For example, if you promise 98% uptime, make sure you have an agreement with your provider that also agrees to 98% uptime.
Design your mashup to have graceful error handling. This could range from a user-friendly error page to a caching system for data feeds and even a standby secondary service provider. For example, if you have a mashup that sends text messages to your users, you can do a mashup with more than one provider—if a provider fails you, quickly switch to another.
This issue is generally more difficult to accept in mashup applications because should core functionality of the system be compromised, it is difficult to proceed. In any case, catering and planning for backup or alternatives in case of an external source breakdown is a must for all mashups if you intend to go into production.
This problem is related to the first. Besides being dependent on the external APIs for functionality, the larger issue could be that the provider of the external API changes its service partially or completely. This could range from the provider being shut down altogether, to the provider changing its business model or commercial terms and it becoming no longer viable to continue with that provider anymore. Even simpler issues like changes in API parameters and accessibility can potentially cause service outage.
For example, a free service could start to charge a fee (or increase its existing fees) and you can no longer afford to include it in your mashup. Sometimes the service itself is no longer sustainable because of licensing issues or the company behind the service abandons its business model in pursuit of another revenue source.
This problem is more acute in areas where the provider is the only one around. Again, planning for alternatives is important if you intend to go into production because this problem can potentially kill your mashup altogether. Some possible defenses against this risk:
Avoid using mashups in cases where there is only a single provider.
Plan for backups and be alert to the happenings of the external providers you're using. Keep an active lookout for API changes as well as news on the company providing your sources. For example, if an online mapping provider is being bought by Google and you use either Google Maps or the online mapping provider's sources you should be wary that either one or both services are likely to change.
Be aware of the competition available to the providers you're using and design your mashup for easy switching. For example, if you need an online map make sure you're familiar with more than just Google Maps and design your system to be able to switch to another online mapping service easily.
Another problem might not be related to reliability or availability at all. If your mashup becomes commercially interesting, it is sometimes quite easy for your external source API provider to extend their existing functionality to include yours and you to be left with an 800-pound gorilla in your backyard. A related risk is for your users to decide that if they are already using the external provider anyway, they might as well switch over to it completely and bypass your mashup altogether.
Again both risks are more likely for mashup applications since a mashup application's main value is in the creative combination of the external sources. Mashup plugins are less likely to encounter this because your main application already has functionality that should be different from external APIs (or else you might want to ask yourself why you're doing it!).
The main defense against such risks is to continually innovate and possibly include more APIs. A mashup application that combines two APIs creatively is more likely to be made irrelevant than a mashup application that combines three, four, five or more APIs and uses them in a creative way that none of your external providers can match by themselves. Remember that your main advantage in creating a mashup application is that you are able to be the best of breed by combining the best aspects and features of various providers to create a unique service for your users.
At the end of the day, although there are significant risks in creating web mashups, there are always ways of mitigating them. Ultimately it's up to you to decide if the risks are worth taking compared to the services you're providing in your mashup.