Standard Interoperability API

Sam at Writely kicks off a conversation about a common interoperability API between all these new applications popping up. We totally agree that such an API would make applications such as ours way more useful. Here are some examples of how such an API might be used:

With open API’s, you could certainly build custom integrations between all of these pieces. However, imagine if there was a a single standard API that everyone used for the general case, making integration a snap!

Here are some features I’d like to see in such an API:

  • Single sign on and Identity management, using an open standard
  • Ability to list and select resources from other services (Maybe using OPML)
  • Ability to easily import documents from one service, and embed them in another, even if the imported document is not publicly published to the world.
  • All the while keeping in mind that the user experience must be easy and seamless

This isn’t the only type of integration imagined by folks. For example, GoingOn is a manifestation of an idea Marc Cantor has often talked about: The Digital Lifestyle Aggregator.

Update: Sam has created a Writely doc to get the ball rolling on this. If you’re interested in collaborating on this, drop him a line.

5 thoughts on “Standard Interoperability API

  1. Identity federation is the more specific basic identity requirement. SSO and identity management are peripheral to the cross-linking API.

    Sxip looks interesting, too interesting actually to be true. If only I could figure out what’s the catch.

  2. Dude, I think Sxip Network is what we were basically talking about the other week.

    Good luck with the integration. It’ll be interesting to see if you can pull it off and even more so as I’ll be integrating all these kinda apps in our product in the coming year.

  3. Pingback: Dave Johnson » Blog Archive » Identity, Mash-ups and Open APIs

  4. So, OLE is basically the equivalent of what you want in the fat-app model, so you may want to look at that in the context of the web & steal some ideas from that.

    You’ll want to have a lot of metadata about the objects that you’re providing. For instance, if I’m writing a webapp word processor and I want to incorporate a graph, is a person going to have to go to the gliffy site to create it? The best situation is that they would just pull a drop down or click a ‘gliffy’ icon and voila your app would be presented within an iframe in the actual document itself. In order to do that, you’ll have to be communicating with other services behind the scenes. The protocol would certiainly contain things like

    “What services do you provide?”
    “What kinds of inputs does this service take?”

    You’ll definitely want to be using MIME types for your content so that these questions are more meaningful. For instance, if someone with a translation application wants to interact with your word processor, you’ll want to let them know that ‘MyFancyTranslationApp’ takes in text/plain or something. Or ‘MyFancyGraphingApplication’ takes in text/csv or sometypeof/spreadsheet

    As for Single Sign On — have you looked into things like the Liberty Alliance?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s