Best practices for mashups

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
  
• Usability
• Maintainability
• Browser compatibility

There's a convention too: identified Best Practices are indicated in blue with BPx, with x being the identified BPs index (for convenient cross referencing).

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:
A mashup basically is a web application. All kinds of dangers (cross scripting, javascript injection, et cetera) are lurking in the dark, looking for weak spots in your application to target their attack at. Fortunately, there are a lot of best practices for web application security, thanks to the Open Web Application Security Project (OWASP)

One important thing OWASP advises is to always assume the worst about data posted to a web service. Validate, validate, validate.

BP3: Validate all data that a web service receives (with respect to for example Javascript Injection)

Usability:
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.

Maintainability:
Mashups are very often built using Ajax. Roughly said, Ajax = Javascript + DocumentObjectModel? (DOM) + XmlHttpRequest?. Javascript is a nightmare for systems administrators. Building clean and maintainable code in javascript is no sinicure. It takes immense discipline. Furthermore, Ajax development and debugging tools are still in their infancy. However, some Ajax frameworks do a very neat job in keeping manual javascript coding to an absolute minimum by providing rich, out-of-the box UI widgets and allow developers to construct the application's views in a declaritive way.

BP5: Use a professional, proven Ajax framework (which one? GWT? Tibco General Interface? Backbase?)

Browser compatibility:
Javascript behaves differently in different browsers. This puts the stability and availability of an Ajax application directly in the hands of the browser vendors. Professional Ajax frameworks do a fairly good job in hiding these browser differences from the developer.

BP6: Either decide to support only one browser (which is perfectly okay for intranet/extranet applications) or avoid manual Javascript coding alltogether (in which case you should really consider BP5).

I am convinced that I could find much more best practices using this approach. But for now, I'll leave it at this.