The future of the web is tiny. We are moving from an era of big, monolithic web sites to small web services being stitched together endlessly in new, innovative ways — small pieces, loosely joined, to use David Weinberger’s phrase. These tiny pieces of the web can be thought of as “microapps“, and MicroApps.org describes the philosophy in greater detail:

MicroApps are small REST applications that are designed from the ground up to be integrated with other applications. Usually, they are not directly useful on their own, but must be integrated into other applications (this is what differentiates a MicroApp from a regular REST application).

And further…

The core idea of Microapps is basically using the web (and REST specifically) as a component architecture to build applications. A microapp is a small application with a very tight focus that can be integrated with other microapps or other web applications via HTTP and a common data format (usually XML, JSON, or RDF).

Don’t worry about the technical details about REST architectures and data formats; the key point is that microapps are small pieces of functionally designed to be put together into larger applications. But if you browse the list of existing microapps, something strange becomes apparent. The vast majority of these microapps are not hosted services, but rather Plain Old Software, which you download, install, configure and manage yourself. These tools would be far more valuable if made available as public, hosted web services. For one, the potential audience would be vastly larger, expanding from the relatively modest set of developers with access to their own web servers running Python, to, well, just about any web developer at all. Secondly, a lot of collective effort could be avoided if each new user of a microapp didn’t have to install and manage the software separately. So what’s the problem here?

Erik Kastner gave a presentation at RailsConf 2008 called Microapps for Fun and Profit. He defines three categories of motivation for someone to create a microapp: “fun” (play, learning), “profit” (AdSense, donations, sponsorship), and “better than money” (reputation, your personal brand, experience). Erik also makes reference to “microprofit” (seen in the snip of one of his slides above), and this hints at the barriers to turning microapps into fully public, hosted services.

Coming up next: why there aren’t more microapps, and what we can do about it.

Twitter-powered social micropayments platform.

I took a break this aftrenoon from the Web 2.0 Expo for the Amazon Web Services Start-Up Tour. It was a cool event highlighting startups which are building their businesses on top of AWS, as well as some good talks by VCs about what they’re looking for in today’s startup space. Highlights included Adaptive Blue founder Alex Iskold describing some unique ways his company is using the services and a talk by Nick Beim of Matrix Partners about doing deep analyses of your customer microeconomics.

Amazon’s Web Services are a hugely important addition to the web 2.0 space, and one who’s possibilities are only starting to be fully capitalized upon. AWS Evangelist Mike Culver described how using Amazon Web Services can eliminate the “undifferentiated heavy lifting” that stands between idea and execution for a startup. I’ve made use of S3, SimpleDB, and SQS for my recent web projects, and am working on incorporating the Flexible Payment Service (FPS) into another prototype now. Taking advantage of these tools helps startups focus on the areas where they really add value, while leveraging Amazon’s infrastructure for the rest.

I have spent much of the last few months working with APIs, and the experience has inspired this list of what’s wrong with APIs:

1. Exposing an API makes scaling headaches worse

   Preparing for traffic spikes has always been a challenge on the web, when a single link from Slashdot or Digg can send hordes of traffic your way and bring your site to its knees. Yet the situation is even worse if you offer an API, because the code on the other end accessing your API may be unrelenting in its pinging or simply badly written, hammering your infrastructure harder than human visitors ever could.

2. APIs have no “eyeballs” to “monetize”

   Advertising has long been the lazy man’s substitute for coming up with a real, viable online revenue model. Attract visitors, then just wait for the barrels of money, right? Google’s AdSense and a host of other online advertising tools made it dead-simple to turn visitors into money, if not always much of it. But the “visitors” to your API are other web sites or other services, and even Google hasn’t figured out a way to make a computer interested in seeing an advertisement (yet).

3. The incentives to expose an API are often weak

   Points 1 and 2, taken together, imply that publishing an API can have real costs in terms of bandwidth, servers, support, and administration. At the same time, there is no obvious revenue model through which to recoup these expenses. This reality can discourage people from making useful APIs available, a point which I’ll post more about soon.

4. There is no standard way to access an API

   The battle to standardize access to web services has raged for over a decade, producing no clear victor and leaving a trail of abandoned and aborted proposals in its wake. Supporters of WS-* and REST have an almost reflexive distaste for one another. Your web service architecture might be RESTful, but is it “high REST”, “low REST”, or simply “REST-ish”?

5. APIs are unreliable

   What if an API you rely on is down temporarliy, or, god forbid, permanently? Isn’t it dangerous to build your business on top of a resource controlled by someone else? Users of conventional software packages have contracts or Service Level Agreements to help protect them against these risks. APIs rarely have the types of guarantees offered by other types of hosted software.

Twitter's "fail whale"... a full year ago, Twitter's API already had 10x the traffic of its website, causing the site to go down repeatedly.

Now, I have an admission: I don’t actually think that APIs suck. APIs have made the internet a much more interesting place, promoting the type of remix culture which can really accelerate innovation. APIs also make economic sense, because they encourage specialization and the associated gains from comparative advantage. In non-economic terms, the availability of APIs encourages creators on the internet to focus on what they’re best at, and leverage APIs for the rest of the functionality they need. Yet in order to realize the full value of APIs and services on the web, we’ll have to find solutions to these five problems. Stay tuned for some of my ideas about a path forward.