Why API is a Must-Have

It’s been clear for a long time now that a cornerstone of any new service is a good, open API.

Twitter proved this point a long time ago. Now, everyone follows suit.

Original image by stevedamron from Flickr used under Creative Commons

Before I was felled by the H1N1, I happily reported that foursquare had publicly launched their API. I had hoped someone would use it to overlay checkins on a map, and voila, someone, namely John Wiseman (@lemonodor) did with 4mapper (h/t TechCrunch).

The app is very simple and seems to have a weird limit on the number of checkins it represents on the map, e.g. only my last 240-some checkins were plotted, but you can clearly see the power of location data.

You can, trust me, more on that in a minute.

More importantly, I’m amazed by how quickly motivated people build apps against these APIs to scratch the itch.

This is what makes APIs a must have feature for every product.

Why? Because there’s no way a development team can build every must-have feature. Trust me, I’ve tried. Stuff always falls out for one reason or another.

When you scope requirements for a product or release, they’re typically force-ranked (h/t Paul) by priority. We use must-have, should-have and nice-to-have. Other scales and schemes exist, I’m sure, but you get the picture.

I prefer fewer options, since beyond the obvious “definitely-in” and “totally-optional” features, they’re all shades of gray, making it tough to draw a line.

Anyway, even after culling the list to must-haves only, you’ll notice some of them fall out along the way to GA.

That’s just how it goes.

This is where the beauty of an API is because chances are those borderline must-haves were definite must-haves in the eyes of some of your users, and to scratch that itch, those motivated users will use your API to deliver those must-haves for you.

Plus, they get kudos for being rockstars, and you get to focus on your core features. So, everybody wins.

Case in point, Rich and Anthony are building some cool stuff with the REST APIs that were delivered in WebCenter’s most recent release, 11gR1 Patch Set 1. Rich showed me infinite scroll today on a live instance built using the REST APIs in PS 1, and it was blazing fast.

If you’re wondering, infinite scroll automagically fetches records when you scroll to the bottom of a page, no pagination necessary. Brizzly and Google Reader are good consumer examples.

This is a feature that didn’t make the list and may never because it’s not a core feature to WebCenter. However, since we’ve built it, it could benefit WebCenter customers.

Win-win.

Back to the power of location data.

Anyone can use the foursquare API and the Google Maps API, one of the granddaddies, to produce a heat map of a single person’s checkins. Foursquare constrains developers to prevent privacy and bandwidth abuse, but conceivably, they could easily create a heat map of any given region’s checkins to show to local businesses.

Foursquare collects some basic demographic information that would help narrow down the data even further. Oh, and they know who I am, making the data targeted.

This is pretty powerful stuff for advertising; the same stuff Facebook has been going after for years.

Twitter is now geo-coding tweets, and Facebook is moving toward geo-location, based on recent changes to their privacy policy, which will make for an interesting showdown between the enormous network that is Facebook (larger than the US at 350 million people) and everyone else.

One final positive thing I noticed using 4mapper implements OAuth to authorize its use of foursquare data, which I assume (hope) is the required way for developers to interact with foursquare data.

I really hope the bad old days of developers storing copies of credentials are gone for good.

As usual, I’ve meandered all over the joint, erm, covered a lot of ground.

So, find the comments to add your thoughts on APIs, foursquare, geo-location, OAuth, etc.