Across the world, websites everywhere brim with overlapping feature-sets.

Content management, tagging, RSS, spellchecking, authentication, search - millions of development-hours every year are spent re-implementing the same features in site after site after site.

For the Google's and Yahoos of this world, such end-to-end bespoke systems are built on rock-solid code and form a crucial part of both their competitive advantage and independence.

For these super-sites, key software has to be proprietary. Building off Google might have saved Microsoft a broken chair and a lot of cash but simply adding an MSN interface to Google-purchased searches could never have made strategic sense.

The long-suffering tail

The long tail of the internet tells a very different story though.

For most communities and businesses, a website is a means and not an end. For the millions of smaller sites that flesh the body of the internet, for these organisations, every line of code is not an asset but a liability.

In most businesses, purchasing bespoke website-engineering makes as much sense as purchasing bespoke truck-engineering. A custom, branded paint-job is a must but a customised chassis is only a scrape away from disaster.

A web-service-world

What if all this generic functionality was provided pre-packaged for us though? What if we could buy tagging or asset management wholesale via web-services?

What if Yahoo opened up their identity silos and we could authenticate users using only a single call to their API (they haven't and we can't by the way)?

Google CMS

How many of the 45% of small businesses that don't have websites might finally get one if the hard part is already done for them?

If Google were to release an API with raw CMS functionality, with versioning, hierarchy and permissions then the website-creation software that the web still so sorely lacks would finally become only an interface away.

furlFunctionality = new Delicious();

So many websites are nothing more than a new interface on a clone of existing functionality. They may well be adding value, but in this case, it's only in the interface. If the core functionality of a website was made available via an inexpensive API though, why bother redeveloping it?

Construction firms don't grow their own timber, they buy it. Different car manufacturers routinely add their own badge, and feature-specs to a the same core chassis. When all a website is adding is an interface, why not simply purchase the underlying functionality?

Could developers sell functionality in exactly the same way as the Amazon S3 sells storage?

Web-serfing

Ecologically-speaking, we are still in a subsistence web. Every application is the digital equivalent of a villager ploughing his own potatoes, butchering his own beef and bricking his own bothy.

We need to specialise. Economies grow richer and more efficient when the people within them become more skilled in specific areas and then trade those specialised, high-value skills.

The web will grow richer and more efficient when functionality can be bought by the call, through clean reliable and robust API's. Not just installable, hacked code-libraries but dependable web-services with service level agreements and fees to boot.

Tomorrows web application today

Do we have to wait for this functionality though or is it already here? Could these types of applications be built today on what's already in place?

Web 2.0 has brought a bloom of web-services and API's. Almost none are charged and few are commercially licensed but they are at least in existence.

A pure web-service application

In the next couple of days I'm going to release an application that takes the web-service / mashup model to the extreme. It is an application built entirely on web-services and constructed purely from AJAX.

The site allows people to create micro-websites for events. Even though those websites have associated maps, photos and data, the application stores no data of its own.

The micro-client

The website is in essence a client, a micro-client. It's a tailored, web-delivered interface to data and services from elsewhere.

Could this represent the future of web-apps? A scalable interface constructed within the browser that adds incremental value to data and services from other, external suppliers?

The questions

What are the technical limitations, what are the business implications, what does an API need in order to be truly useful?

In the next couple of days, I'll be releasing the application that pushes the edge of this approach and will also be following up on some of the issues around data, business and security that it throws up.