The pursuit of APIness (part 7)

Already the seventh post of series “The pursuit of APIness”, and it is now time to conclude by outlining another strategic issue substantially bound to APIs: local expertises. As a matter of fact, since the very goal of an API is to cross the line of existing web property (i.e. a website, a database) and open monitored accesses to data, releasing an API can make other websites orbitting in nearby niches use your API, i.e. use your data, i.e. transform your data into the local reference.

Part 7: Connecting local expertises

“Local expertise” should not be understood as “geographically local” but as “expertise in a particular niche”. On top of being a series of tubes, the web is a tapestry of niches (e.g. “make money online”, “web 2.0 startups”, “reviews of gagdets”, “flash games”, “travel guides”, “maps” etc.). The goal for every webmaster is to make his/her website the leader in his/her particular niche.

Being a leader means having some influence on your followers or on other leaders. Now what’s the best way of having that kind of influence than making your followers use your data? Let’s take an example: Techcrunch, the famous blog commenting the web 2.0 startups ecosystem, has quickly become one of the leader blogs in the niche (quite a tremendous amount of RSS subscriptions). They developed a whole blog network totalizing 15 websites so far, including an interesting project: Crunchbase, a free and organized database containing updated information about startups and startup founders. In a nutshell, Crunchbase is to Techcrunch what Freebase is to Wikipedia: an organized abstraction of pure and cross-linked data. But Crunchbase goes even further: it is possible to embed Crunchbase information in any post, just like you can embed a Youtube video in your blog or a Scribd document in your website (more information here).

Here is an example of Crunchbase widget for Flickr:

This is quite a smart move from Techcrunch: now blogs or websites in the same niche (or elsewhere) can directly embed Crunchbase data into their posts or pages. For Crunchbase data, it’s a first step outside through parameterizable widgets: it’s outside of Crunchbase’s official website, but the data is still enclosed in the widget’s HTML.

Recently, Crunchbase released an API. For Crunchbase data, that’s the second step outside, this time in complete freedom since developers can access pure JSON. Now third-party developers can build layers on top of Crunchbase data, which makes the latter a new reference. The example of Techcrunch is interesting: for it’s usually not easy to get accurate information about private equity fundings and acquisitions, opening access to a comprehensive and cleverly built database simplifies the developer’s life and, in a way, prevents him from reinventing the wheel (although it’s not exactly like an algorithm but it’s more of an information provider).

By extending its reach through widgets and an API, the Techcrunch network is aiming at becoming a comprehensive reference i.e., in the hot web 2.0 startups niche, a local expert. They’re not alone though: seeing the threat coming, ReadWriteWeb recently launched its own companies database too.

Still, the strategy can’t only consist in opening wide access to core data: there is an equilibrium to find between locking all the data (bad move: competitors opening their data could reach your audience) and granting full access to it (bad move too: competitors could artificially bloat by absorbing your content or bury your web application under several layers of mashups).

From APIs to mashups

For an application, a blog or any website, releasing an API may help becoming a local expert. For third-party developers, using APIs makes it possible to connect local expertises.

Say you want to build a cool webapp (who doesn’t?) and provide users with geolocalized pictures of places they’ve been to. The easiest and best way to do so would certainly be to use existing services through their APIs:

• Facebook for profile data and places where the user has been (requires the user’s permission)
• Flickr to find the pictures
• GoogleMaps to display the pictures in a neat map of the world.

The service could work as follows:

1. the user signs up and grants access to his Facebook profile data
2. your web application parses his/her profile and finds relevant places,
3. then gets photos from Flickr tagged with these places (and gets geolocalization too),
4. then create a custom GoogleMap with pictures on it,
5. and displays it back to the user for him/her to interact

Here is a schema to better understand this example of a connection between local expertises (namely expertises in profile data, photos and maps):

Conclusion

Through this series of posts, we’ve been reviewing APIs both on technical and business sides. In these intense times when every hour could bring you a new competitor from the other end of the world willing to lead your niche, it is important to build the basements of your user base and, if your business allows you to release an API, to do so and extend your reach.

A lot of nice people are here to help you building your API:

• experts such as Google’s Joshua Bloch (and his famous keynote on APIs)
• companies such as Mashery, specialized in helping you rolling out your own API
• more advanced tutorials on how to design your own API (now that REST, XML-RPC and SOAP are understood)
• tons of classified APIs at ProgrammableWeb for you to get inspiration
  

I sincerely hope you enjoyed this series of posts. Please feel free to leave a comment!