Skip to content

Public APIs: The True Battlefield of the Platform Wars (and a proposed solution)

A few interesting stories this week have compelled me to flesh out an idea I’ve been having for a while. Details below the fold, but here’s the gist: as the web continues to evolve, we get more and more services that deal with lots of information and these services are currently in the habit of putting out public APIs. However, these companies also control these APIs and they are able to change or even disable them at will – which is fine, legally, but creates huge problems for any other companies that are relying on those APIs.

As the web moves forward I can only suspect that this problem is going to become more common, not less – and so I have at least a vague hint of an idea for how we can go about solving it. I’m curious for your thoughts!

The Context – Public APIs changed or revoked

  • Amazon kills Lendle’s API access – Apropos of nothing, Amazon one day decided to shut down the API access of popular up-and-coming kindle lending service Lendle. Nobody is arguing that Amazon isn’t allowed to do this – it’s their API and they are within their rights to do whatever they want with it. The problem is, where does this leave a service like Lendle? They were providing enormous utility for lots and lots of users and never violated any of Amazon’s policies.
  • Twitter threatens third-party client devs. This also came almost entirely out of nowhere – apparently, now that Twitter has decided they want to turn a profit they’re gunning for anyone who is creating “unofficial” twitter apps – and this presumably includes things like TweetDeck, Destroy Twitter etc. Again, Twitter is within their rights – but the general consensus seems to be that this is a dick move. I’m certainly not about to launch a startup that uses Twitter’s API – even if I had been planning to, this would kill those plans

You’re kidding yourself if you don’t think we’re going to be seeing more of this in the future. I’m not even going to mention Facebook, whose API has been in such a state of flux for so long that writing code against it requires phenomenal patience and deep pockets on the part of any client interested in doing so.

The Complication: Companies Need This Freedom

And you know what? A company should be allowed to make sweeping changes to a public API, whether these are changes that cause it to work differently than it did yesterday or changes that make it a violation of ToS for someone to continue doing something that was legal yesterday. These companies own these APIs and if we somehow insist that they never change the way they implement them then the only recourse these companies could have is to remove public APIs altogether. I totally understand that.

The Consequences: Startups Suffer

But then, look at companies like Lendle which take advantage of these APIs to do truly interesting, unique or useful things. I can only assume Lendle co-founder Jeff Croft woke up one morning and spit out his coffee as he opened his inbox. “Oh, okay, so my company that has been getting all of this press and succeeding wildly is suddenly unable to provide the service around which it’s based. Now what?”

That’s enough to scare me out of putting any serious effort into a startup that relies on a third-party API. I could wake up one morning and realize that an API I had been relying on is no longer available, and now what do I tell my users?

Here’s where a lot of people simply say “Well, them’s the ropes. You knew the risks going in and that’s just how this works.”

And that’s true, but I think we can do better.

What a Solution Could Look Like

I’d like to see a third party emerge that serves as a sort of API Hub. This third party (let’s call them the API Hub) negotiates with anyone who offers a public API. They basically provide a service whereby this API Provider can register a “stable and permanent” API. That’s not saying that they will stop working on API updates or whatever – it just means that they will have to version them moving forward, and every version that goes through the API hub needs to be supported independently.

The API Hub in turn sells stable API access to developers. Why would a developer pay for API access instead of using the free public API being offered by the initial provider? They don’t have to. They are free to build their company on whatever the most recent public API offered by the provider happens to be, and for testing and for getting off the ground this is a perfectly viable strategy. But when they are ready to launch and have enough users that they want to make a stab at stability it’ll be worth their while to pay for access.

Would this work? Would people buy into this? I think it’s worth a shot, because money talks. If every serious twitter client out there was paying for the privilege of using a stable API then that’s going to be a nontrivial source of income for Twitter, I would think, right? Or am I being naive? And if an API Provider is being paid to provide a stable API then suddenly there’s a much greater incentive for developers to use that API, so this could provide a competitive advantage.

Is that enough to get someone like Twitter or Amazon to sign on? Obviously a big part of it would depend on how the contracts were structured, where the teeth are so to speak. But it’s at least worth thinking about, right?

I’m genuinely interested in your thoughts. Does something like this already exist? Is it working? Why/Why not? What are the flaws here? Do you provide an API? Your opinion is the one I’ve been exposed to the least, how would you feel about participating in something like this? Does it ask you to sign away too much? Is it reasonable? What would make this more compelling for you?

{ 5 } Comments

  1. Steven Diomampo | April 2, 2011 at 5:44 pm | Permalink

    I really like your proposed solution to this problem and hope you get some responses from API providers. Their stance is was truly matters. You’d think if they can find a way to pocket a little money from the end users, it shouldn’t be an issue and could work similarly to the “lite” version of games/apps.

  2. mykola | April 2, 2011 at 5:52 pm | Permalink

    Exactly. I’d love a standardized Lite version that I knew I could depend on. It doesn’t have to have every feature that the current Full API has, just a core set of features that can be depended upon.

    Sadly I don’t think we’ll be seeing any major API providers weighing in here, this seems to have gone mostly under the radar. Ah well.

  3. Stray | April 2, 2011 at 6:00 pm | Permalink

    Is there a barrier to us developing this ourselves? That is – to provide a service that decouples the API, and then in future maintain it in such a way that backward-compatibility is kept, or at least gracefully degraded?

    I know there is the traffic / load element to it – I’m wondering whether the burden can fall on the developer to provide that. So we’d maintain a set of scripts in the main languages, that provide your decoupling. You run these on your own server.

    Then it’d be down to the developer to grab the updates as required, but prompted by the service?

  4. mykola | April 2, 2011 at 6:09 pm | Permalink

    Well, then the hypothetical service you’re proposing would be subject to the same problem as any API-based startup is – if Twitter changes their API or even gets rid of it, there’s absolutely nothing our service could do.

    It’s that single point of control that I’m trying to define here – right now, an API’s dependability is controlled by the company that releases it. What I’d like to see, for the good of all, is some way to shift that point of control to a neutral, profit-motivated third party.

  5. mykola | April 2, 2011 at 6:10 pm | Permalink

    Honestly I feel like the only way that could happen though would be for the major players in the API game to get together and create that service. I don’t think you or I could do it – we don’t have the clout. But if Amazon, Facebook, Twitter, LinkedIn etc all got together and decided that such a service would be in their best interest, I think we’d all benefit.

Post a Comment

Your email is never published nor shared. Required fields are marked *