So I'm on my magical patio again consuming a cold beer and thinking about retail customers and the systems that serve them.
I've been asked too many times in my career to replace legacy systems with bright shinny new retail systems. Now, I'm a bit of a nostalgic guy. My first rule of technology is "embrace the legacy". Good thing because not only has that saved millions of dollars for the companies I've worked for, it's also made them millions of dollars.
You see, I've found that the fastest path to innovation is through understanding the past; the solutions to even the hardest problems are always obvious with hindsight. Irony at its best. You don't need to see into the future, you need to see into the past.
Freedom to Innovate
With that in mind, you can free yourself from the excuses of not innovating. You won't need millions of dollars in new systems, a hoard of new employees or a 18 month roadmap to change the way you do business in the new multichannel web. Want to reach mobile phones, app stores, set-top boxes, hoards of partners and affiliates? All you need is a way to tap into all the goodness of your enterprise systems and capabilities. All you need is an API, or as I call it, A Profit Interface.
That's the first step - abstract yourself from the legacy systems with an API - technically an Application Programming Interface (a technology blast from the past). Abstracting from the legacy is a bit like asking a girl to drive you to the prom but not making her your official date. You want to play the field and in this age of retailing that means smartphones, tablets, e-book readers, kiosks, game platforms, connected cars and internet everywhere. APIs let you get there.
Getting Everywhere, Fast
Imagine having a single connector, to say your legacy product catalog, that all those new screens could access quickly. And when the next sensational device arrives, you just snap it in - no coding necessary. How many more sales could you make if your customers had access to your products and services from anywhere? What if another retailer could access your product catalog and offer your complementary items to their customers? That's money, baby!
I know because the innovations I've seen and guided at companies opening APIs have made millions of dollars. I even got a couple of logo coffee cups for my efforts. One more beer, slides into my logo beer cozy. I forgot i got a cozy too.
I really wish I could pay for all this beer with my phone. I always forget my wallet in the car. Hmmmmm..... how to do that without millions of dollars in hardware upgrades? Maybe someone needs to contact the beer distributors about embracing their legacy systems...
Two weeks ago the Wall Street Journal ran the story ‘Sam's Club to Use Wi-Fi to Push TVs,’ highlighting internet-connected TVs which run popular social media or video applications. Last week WSJ highlighted how cable companies are getting their content on the iPad in response to excellent execution by Netflix and Hulu. This week, WSJ reports how businesses like law firm Sonnenschein Nath & Rosenthal, Bausch & Lomb, and Mercedes-Benz Financial are adopting the iPad as a business tool. APIs are all over the business press as early leaders emerge and competitive pressure to succeed in the multi-device web heats up.
Chris Anderson sees the trend. From his excellent feature article in this month’s Wired:
Over the past few years, one of the most important shifts in the digital world has been the move from the wide-open Web to semi-closed platforms that use the Internet for transport but not the browser for display. It’s driven primarily by the rise of the iPhone model of mobile computing, and it’s a world Google can’t crawl, one where HTML doesn’t rule. And it’s the world that consumers are increasingly choosing….
We’ve seen a shift like this before. In the late 90s, consumers adopted the web to search, shop, and socialize. Companies who recognized the shift capitalized (think Google, Amazon, or eBay), and those who couldn't innovate fast enough suffered.
How can consumers reach your service or interact with you on their device (phone/set top/tablet/car/other) of choice? Can your service or data be included or embedded in applications consumers love? What would be the impact if your main competitor’s service was available everywhere and embedded in popular applications and devices?
An open API strategy allows you to engage and capitalize in the multi-device world - and just like we saw in the 90s with websites, companies need to adapt to succeed.
APIs are like a garden hose. They can make things grow.
Well that's what I was thinking as I tried to save my roses from the blistering summer heat here in Dallas, Texas. It really started to make sense when I snapped off my trigger nozzle in favor of a sprinkler. I have the quick connect system so it's a piece of cake to swap out attachments. The 104 degree heat was getting to me, and I started to imagine the hose being connected to retail information and inventory - the API being the quick connect and the nozzles being the interface to consumers.
I'm sitting on the patio at this point, the sprinklers doing the work now, and I'm thinking I should grab a beer and really see where this analogy goes. I watch the sprinkler go back and forth, spraying a pattern of precious water across the lawn - and on my FENCE!
No, the source of life cannot be wasted on a board-on-board fence. I get up and carefully plan my assault on the sprinkler, careful not to get wet (note to self: cold water pelting your body when its 104 is not something you should avoid). The sprinkler has all kinds of adjustment mechanisms. I can adjust the spray pattern left or right, long or short. I can control the amount of water going through the valve and of course there's a timer.
Ahhhhh, this like API infrastructure, the control panel for APIs. Crystal clear. Just like the mechanisms of the garden hose nozzle let your control and target different areas of your lawn, API infrastructure lets you optimize your API for various sections of the market - from mobile developers to affiliate marketers. And just like a great sprinkler system, an API infrastructure lets you scale up to cover your whole "lawn." Finally, API infrastructure provides visibility, letting you see where your services are going and how they are being used.
At its core, an API infrastructure lets you harness and control the power of an API and grow your market, just like a garden hose lets you harness the power of water to grow your lawn.
So you know what I did? The next time I went to talk to a prospect I carried a garden hose, quick connect and sprinkler with me (at least they will remember me).
Analogy complete. No!
One more beer (my answer to Job's "One more thing").
API.... A Profit Interface. Another entry on that soon.
OAuth 1.0 (the current spec version is 1.0a, which fixes a security problem with 1.0) solves an important problem in the world of APIs -- how one web application can give another application API access without requiring that the user give out their password. OAuth 1.0 solves this problem in a clever way through a secure handshake, via API calls, between the two applications. This has allowed APIs to go in places where they could never go before.
OAuth 1.0 works by ensuring that the API client and server share a token, which is like a username, and a token secret, which is like a password. The client must generate a "signature" on every API call by encrypting a bunch of unique information using the token secret. The server must generate the same signature, and only grant access if both signatures match.
The advantage of this approach is that there is no way to find out the token secret, because it is always encrypted when it's sent over the network, and only the client and server have the keys. It doesn't matter if the data is eavesdropped on a WiFi network in Starbucks or captured by a proxy like Apigee -- there's no way to see the secret, so there's no way to impersonate the client based on what's sent over the network. All of this is done without requiring SSL, since SSL can slow down the client and server alike, and make deployment of the API server more complex.
However, both client and server developers found the complexity of generating and validating signatures to be too much. There are many tricky things that a developer must get right, down to exactly what type of "URL Encoding" is used (it's not exactly the same as it's used in other places). If the client or server makes a single tiny mistake in the signature, it's invalid and it's hard to figure out what went wrong.
OAuth 2.0 promises to simplify this stuff in a number of ways:
1. SSL is required for all the communications required to generate the token. This is a huge decrease in complexity because those complex signatures are no longer required.
2. Signatures are not required for the actual API calls once the token has been generated -- SSL is also strongly recommended here.
3. Once the token was generated, OAuth 1.0 required that the client send two security tokens on every API call, and use both to generate the signature. OAuth 2.0 has only one security token, and no signature is required.
4. It is clearly specified which parts of the protocol are implemented by the "resource owner," which is the actual server that implements the API, and which parts may be implemented by a separate "authorization server." That will make it easier for products like Apigee to offer OAuth 2.0 support to existing APIs.
For these reasons, OAuth 2.0 has already been adopted by companies like Facebook, which uses the draft spec in its Graph API. Of course, it's a new spec, which means there are new requirements and use cases that make it more complex. For instance, OAuth 2.0 also clearly lays out how to use OAuth entirely inside a browser using JavaScript that has no way to securely store a token, and it explains at a high level how to use it on a mobile phone or even on a device that has no web browser at all.
Finally, although the developers of the world will not miss generating OAuth 1.0 signatures, they served a purpose, because they allowed a client to send its token and secret securely to a server without requiring SSL. For APIs and devices that do not want to support SSL for performance or complexity reasons, signatures are still a good choice. Right now, signatures have been removed from the OAuth 2.0 spec, but they'll be added to a separate extension spec at some point.
So should you use OAuth 2.0 today? Here are a few things to consider:
- Spec changes. OAuth 2.0 has not reached a stable IETF draft yet. If you implement it today, are you prepared to change your implementation every few weeks until the committee has agreed on a stable version? OAuth 1.0a, on the other hand, is already a well-defined standard that's not going to change any time soon.
- Implementations. There are a number of code libraries for both client and server that support 1.0a today. There aren't as many for 2.0, so you're going to have to build more stuff on your own.
- Complexity. There's no doubt that 2.0 is easier to implement both on the client and server side.
- Performance. If you are unwilling or unable to use SSL for all of your API traffic, then OAuth 2.0 is not a good choice until some sort of signature extension is added to the spec. OAuth 1.0a already supports signatures, which are complex but allow you to securely exchange tokens without requiring the use of SSL.
You can also check out my blog on "When to Use OAuth" for more, and we'll continue to explore this issue as it evolves.
Business Insider recently posted a chart comparing the web site traffic of Netflix.com and Hulu.com over the past few years. The chart shows that in late 2009, Hulu's traffic began to surpass Netflix's. The article's headline suggests that Hulu is "coming up" on Netflix- but these numbers don't tell the whole story.
Much of Netflix's usage comes from the Netflix API, which serves customers using set-top boxes, applications and gaming consoles- allowing users all over to access their content without coming to their website. Google Analytics, Quantcast and Alexa can't tell you about the customer watching videos on their iPad or xBox, or through applications on their mobile phone. In the new world of APIs, multiple devices and multiple channels, website traffic numbers aren't enough- you need to measure API traffic to see what is really going on.
Looking at website traffic alone is like trying to measure Twitter usage by looking at how many people visit Twitter.com via a browser, as opposed to looking at how many people access it through the number of web, mobile and desktop applications that consume the Twitter API.
The problem with looking at the wrong business metrics- like focusing on website analytics instead of the complex ways customers now consume media- is that it can lead you to the wrong conclusions.... and the wrong business decisions. API analytics are an essential business metric in the post-browser era- and a metric that businesses, analysts and press all need to look at as they try to get the full picture of how companies and content are growing and evolving.
