11 Comments

Summary:

As we build technology into everything, creating entertainment, recommendation services and applications that can deliver whatever we need at the moment we ask, a new breed of application is being born, and the currency of this new breed of application is the application programming interface.

401810552_bb08529d36

As we build technology into everything, creating entertainment, recommendation services and other applications that can deliver whatever we need at the moment we ask for it, a new breed of application is being born. Maybe it’s the rise of the federated web. Maybe it’s a network or data; but whatever we call it, the currency of this new breed of application is the application programming interface.

APIs between services are the key, packaging up data generated by one web app and transferring it to another. In chats with entrepreneurs at South By Southwest, the API has become a basic building block, but what seems relatively unexplored is who has access to that building block and the capricious nature of the rules surrounding it. As Twitter showed those using its API last week when it gave notice to app developers that it doesn’t want new Twitter clients, sometimes applications might be building their services on a foundation of sand.

This weekend at SXSW, I had an entrepreneur named Damian Kimmelman, the founder of DueDil explain to me that he was using an API to gather some data from his friend’s company “because he liked their algorithms.” Unsaid was the fact that the guy providing the API was also his friend, but surely that ranked as well. Meanwhile in another conversation, Alex Housley, COO of Rummble Labs, which provides recommendations for businesses, is working with GNIP in part because it has access to Twitter’s firehouse of tweets from an API.

But as the Twitter example shows, there are issues associated with APIs that may mirror issues associated intellectual property licensing. Sam Ramji, of Apigee, which acts as a monitoring and quality assurance service for APIs, agrees. In a conversation at SXSW, he said the technology is there to share content, APIs, and whatever else someone wants, but the contracts and legal system will have to catch up. For example, do the clients using the Twitter API have any legal resource after the microblogging company changed the terms on them? Should they? In some areas, such as the ownership of movies for example, the contracts and business models are in place. But for APIs, the general consensus is that open APIs are good, and enticing developers to use them is only going to be good for those companies seeking to build a platform.

However, as those platforms seek to expand and monetize their user base and their existing data, and as we build out the federated software I described after hanging out at SXSW last year, the issue of API contracts or dependability will have to come to the fore in order to protect those building a business on top of such platforms as well as the users who come to depend on them. Are there people working on this, or are we still at the caveat emptor stage? I welcome any thoughts on this issue going forward.

Image courtesy of Flickr user the trial.

  1. Although we operate ECGridOS in the enterprise space, an increasing number of maverick developers are using our EDI network management API to build their businesses. The President here at Loren Data Corp always agitates, in a constructive way, to build the ECGridOS developer community, get code contributions and applets, etc. We have the early buds of such a developer community, but we are not a consumer social media service, we are a transaction network for EDI enabled trading, so we have a smaller and more specialized cohort. With a 90+ functions and growing, the ability to create and operate what is essentially, your own Value Added Network – if you have the coding chops, is a big deal and comes with certain responsibilities.

    First, if you burn your developers, people who really invested time and treasure in mastering your API and coding up applications, you are screwed. Second: An API based business, a B2B business such as we are, must be involved in he building the future of your developer partners. There is no way around these verities.

    Third: We are a cash flow positive, independent 24 year old business, with a startup mentality, breaking new ground in a very entrenched market (VANs, you know who). Our developers are OUR future, and you will not catch us building a populist wave (even if we could), and then doing a switcheroo with the partners. We had a few early mistakes, but thanks to all of the party’s willingness to communicate and compromise we our now in the threshold of something fantastic.

    I shudder to think of what we could do with VC or angel money, even a very modest placement, but once a wholly-owned one founder ship, …..etc.

    I will close with this thought: One might think that a mighty new media business like a Twitter or a Facebook could not fail, no matter how badly they mismanage their developer community, and I am not saying they are. However, any market lead can suddenly start to erode, and there are many fast movers out there – Twitter has no generic or genetic immunity from a colossal mis-step.

    We here at Loren Data Corp say something like that in our daily calisthenics and brain-cleaning sessions with the company’s life coaches and our part time Dachshund trainers.

    Share
    1. You and the author have collectively raised a point that I don’t think most people usually see at first, that revenue generating b2b and free b2c service API’s are usually very different beasts.

      Twitter is clearly still looking for ways to monetize, and the API potentially costs them money by taking eyes away from ads. But part of their success is clearly based on interoperability with millions of other websites and programs (something like 50% of twitter interaction is through 3rd party software… see: mashable). So they’re stuck between maximizing revenue and maintaining an open platform.

      Companies like yours that no-doubt generate revenue with your interoperability focus on breadth, quality and consistency of service. It actually sounds like a good position to be in. Presumably your clients’ goals and yours are perfectly aligned, instead of being in opposition like Twitter.

      Also, Author is quite right about API’s being the new black. I just launched a tiny, zero-funds little webapp and collected survey data from everyone that wanted notifications. Surprisingly, a huge percentage said they’d want API access to even the smallest feature set. Now I have to seriously consider how I’m going to deploy that in a way that is, as I mentioned before, well documented, consistent and feature-rich.

      That’s quite a bit of planning and proper execution for one guy with a small site, but people demand programmatic access now… it’s just a standard expectation.

      Share
  2. I think API’s are here to stay and if anything, only going to proliferate. They enable classes of applications that were not thought of by the authors resulting in a sum greater-than-parts effect (aka mashups). In the cloud, API’s provide serious automation to devops folks when the server sprawl happens. We recently released our public beta of http://blitz.io focused squarely at load and performance testing for API’s. Blitz itself, of course, has an API too so you integrate load and performance testing as part of the continuous deployment cycle.

    Share
  3. I read this whole article and I like it. It points out some disturbing aspects of building Apps on APIs. But I can’t figure out the title, “Are APIs the New Black?”. What does that mean?

    Share
    1. Sorry, it was a fashion reference. APIs are trendy at the moment, maybe the equivalent of a wardrobe staple.

      Share
  4. I suspect till the industry settle down on a monetizing model for these platform companies they will be under pressure to look for in any possible ways. it is hard for them to admit that they are just another layer of onion on this internet infrastructure.

    Share
  5. APIs and Integrations are awesome. Especially for a small company like us, integrations give us the leverage our larger friends have in terms of user base, marketing resources, and audience to promote our product.

    In the end, its all well and good because the integrations are usually a feature that customers really want and can use.

    Share
  6. Stacey, enjoyed your article. Other than Apigee, have you come across any other companies which help startups build and/or manage APIs? I assume as APIs become even more integral to more online companies, a whole ecosystem of businesses (e.g. Gigya and Janrain for sign up) will rise up to help sites deal with APIs.

    Share
    1. Looks like Mashery is another one.

      Share
      1. And bear in mind 3scale that offers a comprehensive solution for API providers to manage not only the technical layer of their API (keys, policies, rate limiting, etc) but also the whole business dimensions (Business partners, developer community, interactions, communication, support, signup process, etc) needed to build a solid long term business on your API.

        Share
      2. Those that focus solely on API issues, no. I do think that the rise of PaaS offerings capitalize on this trend however.

        Share

Comments have been disabled for this post