This is a first attempt to identify the do's and don'ts - Best Practices - concerning Mashup development. Googling for "mashup best practices" does yield a few usefull results, like for example:
The blog post "Towards best practices for mashups" by Mark Baker
The blog post "Mashups: Business Models and Trends" by Richard McManus on ZDNet
But because of the "newness" of mashups, we haven't collected much practical wisdom about them yet (or I have just not been looking hard enough). Therefore, I decided to approach these best practices from different directions by looking for best practices for aspects of mashups. Mash these together and you get (tada): best practices for mashups.
So far I have (just briefly) explored these mashup aspects:
- Web API dependancy
- Security & safety
- Browser compatibility
Web API dependancy:
Mashups combine functionality from several different Web APIs. This makes a mashup dependant on the availability and stability of those WebAPIs. As a consequence, a Mashup's "use-by date" is limited to the earliest use-by date of the Web API's it depends on. Web API providers periodically introduce new versions of the APIs, and usually keep old and new versions alive for some time. But at some point, the old versions will be shut down. By that time, all mashups still depending on the old version will become invalid.
BP1: Keep Web API interfaces stable. It is safe to add new functionality. But it is unsafe to modify the signatures of existing API interface methods. Ensure downward compatibility
BP2: Make Web API functions robust and flexible in the data it accepts (e.g. date formates, zip code formats, et cetera).
Security & Safety:
One important thing OWASP advises is to always assume the worst about data posted to a web service. Validate, validate, validate.
A Mashup is doomed if its user interface does not meet the user's objectives and expectations. Know the user, know what his/her objectives are. Design a user interface that helps the user to meet these objectives efficiently and effectively.
BP4: Make interaction designs, build UI prototypes and do usability tests.
BP5: Use a professional, proven Ajax framework (which one? GWT? Tibco General Interface? Backbase?)
I am convinced that I could find much more best practices using this approach. But for now, I'll leave it at this.