WebAPI is the new RSS!

Huh!? Well, I don't mean WebAPI's are going to replace the functionality of RSS, but certainly the need for a WebAPI on a provider model site is becoming a mandatory requirement, as did RSS for content sites.

Why is this so? Well, if you think about the maturity model for content sites, and if we take something like a blog or river of news, as the overall surface area is sparse, it's easy for people to read individual content sources. But as that surface becomes more dense, the time taken to move between sources becomes onerous, so there is a need for some form of aggregation capability. This, together with the evolution of use of a technology (RSS is now the "data interface" for developing against an RSS feed as a data source rather than "just" a way of syndicating content), and you have a technology curve that responds to maturity and density.

So back to the WebAPI model. There are more and more sites that are aggregation points for data, take Technorati for example, that synthesize new functionality from the inherent behavior of their sources. So rather than just being a river of news, or a blog aggregator, they track the links between blogs to measure relevancy and meaningfulness (as dictated by users behavior). While you can access their function points from their web front end, being able to integrate their functions into your own applications to create cross-functionality is far more powerful, hence the need or a WebAPI.

And finally, when you look at any web application being developed today, it's almost mandatory that you factor in your WebAPI layer into the overall application architecture, to ensure you have a managed, designed, predictable way of providing programmable web access to your core functions (the ones that make sense from a web integration perspective).

Look at it another way though. Think about all the scenarios you envisaged for a particular function or feature in your app, take for example, the part of your application that can estimate the risk associated with a range of factors. Now, there is a fair chance that that piece of functionality has considerable IP behind it, and the range of scenarios you planned for in your app is probably only a subset of all the possible uses of that feature/function. Now, looking from a software economics point of view, you're not getting complete return on your investment in that function/feature. So if you could open that piece of IP to the rest of the world vis-a-vis the web, and enable other developers to create uses for that feature/function, and build a charge model around doing that (your billable WebAPI), then you're increasing your ROI for features/functions of your application that are not being fully utilized.

And if you think this only applies to the public facing world, think in terms of internal ROI. Deploying that next Enterprise Web App (of middleware, SOA, whatever) that has some cool functionality that could be leveraged by the wider enterprise in future projects, where the usage can be reported in terms of different applications (WebAPI usage/requestor dashboard) gives the enterprise great visibility in terms of those pieces of WebAPI functionality that are high-value and/or high-use.