A mashup is a hybrid Web application that combines complementary elements from two or more sources to create one integrated experience. Content used in mashups is generally sourced from a third party via an API or from Web feeds (e.g. RSS or Atom). Basically, the point is to take multiple data sources or Web services and turn them into something useful. The idea of combining Web services is not a new one, but it has gained immense traction in recent times and will likely continue to grow in popularity. In this entry I will be discussing both the promising future mashups offer and also potential pitfalls.
Opportunities and innovation
Mashups offer developers and entrepreneurs alike an enormous and continuously growing number of opportunities to create services with free, third-party data and processing. This lowers the bar for newcomers to get in the game and fosters innovation. It's also possible for mashups to make their service available via a public API and allow it to be "supermashed" by another developer.
In many ways, Mashups are the precursor to full Service-Oriented Architectures. SOA expresses a perspective of software architecture that defines the use of loosely coupled software services. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.1
New markets and revenue streams are created by combining independent, complementary data sources. Mashups offering valued and useful services that attract users and generate revenue are springing-up all around. Anyone from a lone developer to a business can leverage public Web services to build sustainable business models.
Let's take some time to think about the caveats. One thing remains constant with mashups that use third-party sources: Questionable reliability. This isn't to say that mashups aren't reliable, it simply means that you are not in control of the primary source of data for your Web application. When your sources are offline, your mashup is offline as well. One way to avoid this problem is to keep a constant and fresh cache of all queries made to your data sources in case of a service outage. Caching is a good idea in general as it will definitely speed-up repeat requests.
Issues to watch out for when developing mashups:
- Rate limiting
- Many public APIs will limit the number of requests an application can make within certain period of time. This can be done by tracking the number of requests made by a single IP, or the system may require authentication and can track usage by that means. This is another issue that can be partially or fully solved by request caching.
- Keeping a current cache of recent requests can help keep your service online until your data source(s) return. If more than one public API is available for the information your mashup requires then a fallback mechanism may be implemented to allow your mashup to "switch over" to another data source until your primary source has been re-established.
- Vendor lock-in
- This could be a huge problem in the future as more and more mashups are created. If a public API that serves map data to thousands of mashups and Web applications suddenly goes offline for 24 hours, forever, or starts charging for their service? An example of keeping all your eggs in one basket.
- Licensing restrictions
- Some public APIs restrict what you can use them for and sometimes which APIs you can use them alongside with. Be sure to thoroughly read any restrictions which may apply before going live with a mashup.
About the author
Trackback URL for this entry:
Spam protection by Akismet
Post a comment