APIs are a big part of the future of the web ecosystem. To draw a parallel with the human body we could say that APIs are becoming the nervous (or even neuronal) system of the web. APIs are like nerves transporting information from different sensors (other apps and services) so that the brain can make a decision.
There is clearly a lot of different APIs and different APIs category as you can see in this Programmableweb screenshot .
There will be even more categories in the future. But the idea of that blog post is to categorize the API ecosystem differently.
First we can categorize API around what they do, just like 3scale did with 3 main categories:
- Logic APIs : provide a service, an algorithm to transform data into something else. Google translate, or Google goggles are good example. You send them data (a picture, a text) and they analyze and send you back a translation or the name of a product. A payment API could also go in that category as it provides a series of process on demand.
- Data APIs : this is the largest family that can fit a lot of API. They just provide raw data that are exploited by apps, or by other API. We’ve seen emerging recently the “data supermarket” : Factual, Infochimps, DataPublica in France, Microsoft Azure Data Market Place are marketplaces where data providers will come to give or sell sets of data, or allow users to query datasets, mostly through API. Open Data website by government are an example of data market specialized in public dataset. PFM services could be an example of API that provide a lot of data about a user consuming habits. Those supermarkets are not yet one single API but we can see that coming. In the near future: if you want data, you’ll call one of those datasupermarket API and select in drill down menu which datatsets you need and you’ll pay according to the freshness are granularity of the data.
- Presentation API : provide the layer of visualization that can put the data and algorithm APIs in tune. Google map is a good example of presentation layer to display geo data. Dipity http://www.programmableweb.com/api/dipity is another exemple : it allow you to show inormation on a timeline.
I’ll try to split the different type of API in categories that would be the most common needs for most the apps developed. To continue with the body analogy, we could say it is the main nervous system.
First you got the context APIs : this is the most common API you will find, giving information about who, what, when and where a user is. Those contextual informations provided by APIs on specific services will influence the app being used. We can slplit those “Context APIs” in sub-categories.
- Who APIs : facebook is the obvious one, even though twitter, gmail and others are also doing a good job at it. The developer will use one of the other according to what he needs more for his app : virality and social graph he will obviously use Facebook or Twitter, more security (knowing the real identity) he will use a bank account are an identity provider that are trying to create a market around that identity layer Miicard is an example http://www.miicard.com/.
- When APIs : When API are more difficult to find. There is a time stamp API , but Twitter or Foursquare could be a good example in that category, providing data on where and WHEN a user was.
- Where APIs: this is the most obvious one : geo data is what started the API business. Companies like simpleGEO is trying to achieve the creation of the ultimate where api. Their claim could be : just give us a lat/long coordinate and we’ll give you just what you want around that point : the address, the weather, the closest subway stop, the density of the area, the shops and promotions around… . This API by SimpleGeo is a good example (it is actually called context api) where you can find geocoded information, demographic data, weather…
Interest API are a fairly new category. They could be a sub category of the Who API as they give even more information about the user. Facebook is again an obvious service that provide those data but there are some more precise one : services like pearltrees are really interest graph. They give you the main area of interest of a user and its favorite sources. Pinterest, the rising start up du moment, is another example of an Interest service. Those interests API provide a good asset to developers, they can tap in what the user likes, what subject he’s specialized in. The Payment graph theorized by @tek_fin and that square is building is also another form of interst graph (where I spend my money is where i have my interest).
Interest is cool, but you know what is cooler ? INTENT API
Intent is the real gold of the internet that ealmost every B2C service are app is tring to gather. Google 40 billion $ business is mostly based on selling purchase intent data. So where is the Intent API ?
Maybe Twitter needs a category of its own. It can by itself provide a lot of context (who, what, when) but also interest, mindset… This is actually one of the true power of twitter. Its unique API can provide a lot of different information. A company like Needium is trying to create that intent API just based on tweets analysis in a specific place and anticipate what a user will need.
In the near future the developer of an Application (mobile or on the web) will develop a service that will be optimized by information provided by those API : in which context are my users, what do they like/dislike or want, what did they do before…
Maybe we’ll see emerge Meta-API that centralized in one API all the others APIs of a category. A developer we’ll have to learn how to interact with one API, and this API will take care of the relationship with all the other sub-APIs. We could imagine a developer will be offer choice : around those lat/long coordinate you want the shops and restaurants alone with users rating : do you want the info from Foursquare, Yelp are a mix of the 2. We already see those in the category of shipping where metaAPIs like those one offer merchant to choose between all the different shipping services available.
A service like http://www.mashape.com/ seems to be trying just that, and SimpleGeo s another great example.
Standing in the API middleman position sounds to me like a nice plan. Behind all that there are still business models that can be created :
- group API calls buying, a meta API could sign just one contaract with a fee based API and split the bill with all the users behind
- you can imagine affiliation on APIs : you get money because you bring API calls to specific APIs
- For read / Write API you could imagine that the Meta-API is used as a buffer for information upoloaded to the API owner. You can tell them : I have a bunch of fresh data for your service but you need to pay if you want me to update it.
Of course APIs are not a stand alone product; they are just a tool that allows user to plug directly in a specific service. But I am quite sure that we’ll see emerge that market of API and meta-API around context, interest and intent.
- SimpleGeo APIs Closed, But Places Data is Open (programmableweb.com)
- Twitter Ads? « There is no Advertising API, » Says Twitter (programmableweb.com)
- ProgrammableWeb predicts that ‘Every Company Will Have APIs’ (thenextweb.com)