One of the most important developments of the web 2.0 era is the proliferation of full featured, bidirectional APIs. APIs provide a way to “federate” web services from a single website to a distributed network of 3rd party sites. Another important web 2.0 development is the proliferation of web Apps (e.g. Facebook Apps). Apps provide a way to make websites “extensible.”
The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).
One of the most important developments of the web 2.0 era is the proliferation of full featured, bidirectional APIs. APIs provide a way to “federate” web services from a single website to a distributed network of 3rd party sites. Another important web 2.0 development is the proliferation of web Apps (e.g. Facebook Apps). Apps provide a way to make websites “extensible.”
The next step in this evolution is to create web services that are both federated (APIs) and extensible (Apps).
In my ideal world, the social graph would not be controlled by a private company. That said, Facebook, to its credit, has aggressively promoted a fairly open API through Facebook Connect. Facebook has also been a leader in promoting Apps. For Facebook, creating extensible, federated services would mean providing a framework for Facebook Connect Apps – apps that extend Facebook functionality but reside on non-Facebook.com websites.
Consider the following scenario. Imagine that in the future a geolocation data/algorithm provider like SimpleGeo takes Facebook Places check-in data and, using algorithms and non-Facebook data, produces new data sets, for example: map directions, venue recommendations, and location-based coupons. The combination of Facebook’s data (social graph and check-ins) and SimpleGeo data/algorithms would create much more advanced feature possibilities than either service acting alone.
With today’s APIs, if, say, Gowalla wanted to integrate Facebook plus SimpleGeo into their app*, they would basically have 3 choices:
1) Embed Facebook widgets in Gowalla. These are simple iframes (effectively separate little websites) that don’t interact with SimpleGeo. Gowalla would just have to sit and wait and hope that Facebook decided to bake in SimpleGeo-like functionality.
2) Pre-import SimpleGeo data. This significantly limits the size and dynamism of the SimpleGeo data sets and doesn’t incorporate SimpleGeo algorithms, thus severely limiting functionality.
3) Host an instance of SimpleGeo’s servers internally. This requires heavy technical integration, undermining the main benefit of APIs.
In a world of extensible APIs (or “API Apps”), Gowalla could instead send Facebook data back to SimpleGeo. The data flow would look something like this:
(Note how there are three parties involved – @peretti calls this a “data threesome”). This configuration is much simpler to integrate – and potentially much more powerful and dynamic – than the other configurations listed above. You could implement this today, but it would create user experience challenges. For example, Gowalla would be sending Facebook data to a 3rd party (step 3), which might (depending on the data sent) require explicit user opt-in. Things become more onerous if SimpleGeo wanted to share its own user data with Gowalla. That would require an additional oAuth to SimpleGeo (authorizing step 4).
Allowing websites to be federated and extensible will open up a whole new wave of innovation. Ideally some spec like oAuth could include the multiple authorizations in a single authorization screen. Facebook could also do this by allowing 3rd parties to be part of the Facebook Connect authorization process. Inasmuch as Facebook’s seems to be trying to embed their social graph as deeply as possible into the core experiences of other websites, allowing extensible APIs would seem to be a smart move.
* I have no connection to any of these companies (Facebook, Gowalla, SimpleGeo) and have no knowledge of their product plans beyond their public websites. I am imagining functionality that Gowalla and SimpleGeo might include someday but for all I know they have no interest in these features – I just picked them somewhat arbitrarily as examples.