Don’t mean to go Bitcoin heavy around here, but just ran across this article about how Bitcoin is basically an API for money and found it fascinating:
Traditional money does have APIs, but they are closed. You can program the merchant API of the VISA network if you are a trusted merchant. You can send and receive FIX messages if you are a stockbroker or exchange. Regular people, however, don’t even have APIs into their bank accounts, let alone the broader economy. Bitcoin changes all that by not only offering an API for accounts (wallets) and transactions, but also making that API available to everyone.
This idea, providing an API for something that doesn’t have one, is one of the more fascinating to me and a space I expect we’ll see lots of activity over the coming years. This, more or less, is what the whole spime/internet of things/industrial internet is about: Giving things that couldn’t talk the ability to talk through APIs. Not surprisingly, I’m especially interested in what this means for brands and how they can build out their own APIs. A few years ago I wrote about Starbucks APIs and, in a lot of ways, we think about Percolate as providing a similar interface for brands by codifying it into the system and making it available to consume via API.
January 6, 2014 // This post is about: api, Bitcoin, brands
Ars Technica has a great piece about how the Chevy Volt came to have an open API and what it means for the future of the car. Here’s a snippet:
Schwinke said OnStar was already working with a number of other partners to leverage ATOMS’ cloud interface—among them electric companies who were looking to extend their “smart grid” services to Volt vehicles. “We’ve been doing some demonstrations and prototyping with public utility companies for smart grid command and response,” he said. “The utility companies can send instructions to the car to control when it charges and when it doesn’t. It can save the car owner money, and flatten electrical demand curves.”
November 26, 2012 // This post is about: api, cars, Chevy Volt, OnStar
People like to use new technology as a metaphor and API seems to be bubbling up as a good choice. Here’s Alexis Madrigal on Occupy Wall Street as an API:
What an API does, in essence, is make it easy for the information a service contains to be integrated with the wider Internet. So, to make the metaphor here clear, Occupy Wall Street today can be seen like the early days of Twitter.com. Nearly everyone accessed Twitter information through clients developed by people outside the Twitter HQ. These co-developers made Twitter vastly more useful by adding their own ideas to the basic functionality of the social network. These developers dont have to take in all of OWS data or use all of the strategies developed at OWS. Instead, they can choose the most useful information streams for their own individual applications i.e. occupations, memes, websites, essays, policy papers.
I find the examples he uses after this paragraph a bit tenuous, but I really like the API metaphor in this example and generally. It’s a simple way to understand how distributed systems functions. (Franchising, for example, was essentially an API before people were talking much about APIs.)
What happens, though, when you take it further like Amazon did? Essentially the company decided that everything must be an API: No functionality produced could exist without being a simple service that any other group in the company could reach. It was probably best explained in an accidental Google+ post by a Google engineer a few weeks ago who used to work at Amazon. Here he explains Jeff Bezos’s service mandate:
1) All teams will henceforth expose their data and functionality through service interfaces.
2) Teams must communicate with each other through these interfaces.
3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care.
5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6) Anyone who doesn’t do this will be fired.
7) Thank you; have a nice day!
What happened next was pretty amazing. After building all these services Amazon started exposing them all publicly. In designing their company around APIs they actually discovered a second business (Amazon Web Services) that they are dominating. In essence the act of simplifying the company down to a set of service calls helped them see where their greatest strengths lay. It’s an interesting approach and one I can only assume we’ll see more companies follow.
November 18, 2011 // This post is about: amazon, api, OCCUPYWALLSTREET, ows, services
Left this in the comments of Neil’s post about the possibility of agency APIs: “The real data in a creative agency probably lies somewhere in ‘ideas’ (thoughts, sketches, designs, presentations). Starting to think about how an agency would build an API on top of that is very interesting (more for the agency itself than clients). But the problem there is one of structure: To build an API requires starting with structured data. The reality is that most of what agencies do is still mostly soft and not-so-easy to arrange.” I then went on to talk about brand APIs a bit, which I still think is a really interesting concept but haven’t put enough thought around to understand properly yet. Go read the whole thing and feel free to skip my comment.
November 2, 2011 // This post is about: advertising, agencies, api
