APIs: A Strategy Guide

Chapter 1. The API Opportunity

APIs are a big deal and they are getting bigger. Pioneering companies such as Google, Facebook, Apple, and Twitter have exposed amazing technological solutions to the public, transforming existing businesses and creating new industries. Central to these companies’ successes are the APIs that link people and their computing devices to the underlying platforms that power each business and that tie these companies together behind the scenes.

The world is already changing. Consider the following examples:

• Salesforce.com built a large, rich partner ecosystem by opening core services for partners to innovate and extend. Today, more traffic comes through the Salesforce API than through its website. As of mid-2011 more than 60 percent of the traffic to Salesforce.com comes through APIs.

• Amazon opened its core computing infrastructure as Amazon Web Services (AWS), accessed via number of APIs, and now serves more bandwidth through AWS than through all of its global storefronts combined.

• Twitter is the most visible example of a business almost entirely based on an API and an ecosystem of developer applications.

• Netflix has completely reinvented how we consume movies and TV shows with streaming to hundreds of different devices, upending not just the video rental industry but also impacting large adjacent markets such as cable TV. APIs allow Netflix to support a multitude of devices in an affordable manner.

• NPR has infused its API into the engineering culture of the digital media division. The API drives the website, mobile apps, and all other forms of distribution and syndication for the company. The API has also transformed the company’s relationship with its member stations and the way that NPR shares content with them.

Now consider these industry trends:

• Smartphone sales passed new PC sales in early 2011, and Morgan Stanley predicts that by the end of 2012, there will be more connected mobile devices in the world than PCs.

• CTIA (the wireless industry association) has determined that there are already more wireless devices in the United States than people.

• Analysts are competing to predict how many mobile devices will exist in the future. The GSMA (another wireless industry association) predicts that there will be 20 billion connected mobile devices by 2020, and Ericsson CEO Hans Vestberg predicts 50 billion. Meanwhile, Marthin De Beer, Senior Vice President of Cisco’s Emerging Technologies Group, projects that count to be over a trillion by 2020.

• Cisco predicts that while Internet traffic originated by PCs will continue to grow at 33 percent per year, traffic originated by non-PC devices will more than double each year by 2015.

• Facebook accounts for over 25 percent of total Internet page views at this writing, and APIs drive both the Facebook products and its ecosystem.

• Over 30 percent of Internet traffic during US prime-time hours comes from Netflix streaming, which is delivered and managed via APIs.

These statistics point not only to an explosion of overall Internet traffic, but also to a huge shift in the distribution of this traffic towards apps and devices. Looking at these accelerating trends, it’s very easy to imagine that APIs will likely power most of your Internet traffic within a few years.

Why We Wrote This Book

As authors, we are coming at this topic fresh from our experiences in the trenches. Daniel Jacobson led development of the NPR content management system and the API that draws from that system. The NPR API is now the centerpiece of NPR’s digital distribution strategy, transforming NPR’s ability to reach its audience on a wide range of platforms.

Today, Daniel leads the development of APIs at Netflix, whose API strategy is in the critical path of the Netflix streaming service. Netflix’s ability to provide rich video experiences on hundreds of devices is powered by this service and has dramatically increased the rate at which new implementations can be built and delivered to new devices. Through this program, Netflix’s user base has grown tremendously, resulting in API growth from under one billion requests per month to more than one billion requests per day, in one year.

Greg Brail writes based on his work as CTO of Apigee, where he has helped implement dozens of API programs and been exposed to many more. In this role he is also able to draw from the collective wisdom of the Apigee team, who has met hundreds of developers and also learned from hundreds of enterprise API programs.

We wrote this book to help people understand the potential of APIs. Additionally, we want you to go into creating an API with your eyes wide open. This book is not a programming manual but a best practices manual. You need to understand both the opportunity and the tactical issues related to creating an API.

This book will also introduce business executives and technologists to the land of API opportunity. To be sure, the world of APIs involves lots of technology, but what often gets lost in the shuffle is the business impact of APIs. This book is about how to think about APIs from a business perspective and how APIs can have a positive impact on your business.

We also want to educate you on what you’re getting yourself into when you decide to develop an API. What are the implications of offering an API, not just from a technology standpoint but also in terms of business strategy, legal and rights considerations, and relationships with partners?

What we are going to demonstrate is that APIs are having a profound impact on the world of business—and that the time to act is now.

Unlike many other discussions of APIs that exclusively look at the way that large Internet-based companies use APIs publicly, this book also emphasizes the private use of APIs, which we believe has an even greater impact than many of the more prolific public API programs you often read about.

As authors, we must keep one foot in the world of technology and one foot in the world of business. To that end, we hope to educate creative executives and technologists about how to put APIs to work in the context of their own businesses.

In this book, we’ll talk about:

• The business opportunity for APIs

• Examples of companies using APIs to transform their business and in some cases their industries

• Business models being used for APIs

• What an API value chain looks like and how to enable the different pieces of that value chain

• Considerations for crafting your API strategy and responding to concerns and objections

• Issues around API design, especially how to make adoption easy for developers

• What to do about API security, including coverage of OAuth

• The legal implications of running an API business, including privacy and data rights

• Considerations for operating your API at scale

• How to think about metrics and measuring your API program

• Engaging developers and building community to drive adoption of your API

In summary, this book offers a roadmap for using APIs to transform your business.

Who Is This Book For?

There are a range of books on the technical aspects of APIs, including books about REST, OAuth, XML, JSON, and others. This book is not intended to compete with those books. In fact, although it is virtually impossible to address APIs without delving into technical approaches, this book is not targeted at the technologists who build or directly consume APIs. Rather, this book is designed for the people who need to make the strategic decisions about whether an API is a good idea for their company.

Target audiences for this book include C-level executives, members of the business development teams, product managers, and technical evangelists. Of course, there will be plenty in this book for technologists as well, but at a higher level.

What Is an API?

API stands for application programming interface. An API can provide a hook for colleagues, partners, or third-party developers to access data and services to build applications such as iPhone apps quickly. The Twitter and Facebook APIs are famous examples. There are APIs that are open to any developer, APIs that are open only to partners, and APIs that are used internally to help run the business better and facilitate collaboration between teams.

An API, then, is essentially a contract. Once such a contract is in place, developers are enticed to use the API because they know they can rely on it. The contract increases confidence, which increases use. The contract also makes the connection between provider and consumer much more efficient since the interfaces are documented, consistent, and predictable.

How Is an API Different from a Website?

An API is quite different from a website. A website provides information on demand. A company puts content out in the world, and people consume it. Websites have no contracts or structures around the use of content. If content on the website changes, visitors who come next get the new content. Their browsers are not affected, and any change is transparent to the user. If you dramatically redesign the website, the only impact is on the user accustomed to seeing the content laid out in a particular way. Humans are great at visual pattern matching; we can quickly adjust to a new design and find what we need. That doesn’t mean that users don’t complain when their favorite site is redesigned, but they almost always adapt.

An API is quite different because it has a contract, and programs are built on top of that contract. Programs, unlike humans, are not flexible and almost always terrible at pattern matching. If you alter anything in the contract of the API, the ripple effect on the apps built on top of it is potentially quite large.

Our Working Definition of an API

Technical definition: An API is a way for two computer applications to talk to each other over a network (predominantly the Internet) using a common language that they both understand.

APIs follow a specification, meaning:

• The API provider describes exactly what functionality the API will offer

• The API provider describes when the functionality will be available and when it might change in an incompatible way

• The API provider may outline additional technical constraints within the API, such as rate limits that control how many times a particular application or end user is allowed to use the API in a given hour, day, or month

• The API provider may outline additional legal or business constraints when using the API, such as branding limitations, types of use, and so on

• Developers agree to use the API as described, to use only the APIs that are described, and to follow the rules set out by the API provider

In addition, the API provider may offer other tools, such as:

• Mechanisms to access the API and understand its terms of use

• Documentation to aid in understanding the API

• Resources such as example programs and developer communities to support those using the API

• Operational information about the health of the API and how much use it is getting

Note

Remember that the structure of the API is part of the contract. The contract is binding, and it cannot be changed casually.

You should treat an API like a software product, taking into account versioning, backward compatibility, and ramp-up time to accommodate any new functionality. There should be a balance between supporting your existing base while at the same time keeping up with necessary changes so that your API grows with your business and follows its planned evolution.

This does not mean that the API can never change. On the contrary, an API is an online product that can change almost constantly to meet the needs of the business, or to serve the current traffic load in the most efficient way. But these are changes to the implementation, not to the interface. When done right, the implementation of an API can change on a daily basis, or even more often, while the interface remains consistent.

…But APIs and Websites Have a Lot in Common

APIs, like websites, are expected to be available 24/7, 365 days a year. Developers, like website users, do not have much patience for “scheduled downtime” every Saturday morning. All of this can create a challenge for building an API on an existing enterprise technology infrastructure, using systems that may have been designed with an “end of day” cycle, after which they are shut down until the next day (such as banking systems).

Successful websites can, and are, updated continuously to change the design and tweak features. This is possible because websites are live entities out on the network that can be easily changed without changing the clients—there is no need to push a software update to the users.

APIs are not much different in this respect. Assuming your API remains backward compatible, an API program can introduce new features and change the implementation of existing features without “breaking” the clients. As long as you uphold the contract between your API and the developers who use it, the API can change on a “web schedule” rather than on an “enterprise IT schedule.” The result is a better, more responsive API program.

In fact, changes to both APIs and websites can be driven by analytics on behavior of the applications and end users. In both cases, a good design and product management team constantly checks the analytics to see what parts of the site or API are succeeding and which are failing. The result should feed into regular development sprints, which over time build a much more robust API or website.

Who Uses an API?

We call the company or organization that offers an API the API provider. This book is largely aimed at API providers (or those who are thinking about offering an API).

We decided to call the people who use your API to create applications developers. It’s true that many types of people may be interested in your API, including business owners, marketing gurus, executives, and others, but the people who will eventually create the applications are developers. Developers are the primary audience for your API.

We decided to call the people who use the applications that developers create end users. They are the secondary audience for your API and often the audience driving many of your API decisions. Depending on the content made available via your API, you may have particular concerns to address, such as copyright, legal use, and so on, that relate to this secondary audience.

Types of APIs

We see two types of APIs: private and public. No matter what you may hear in the media, private APIs are the more prevalent variety. You know about the Facebooks and Twitters of the world and their use of APIs. What you probably don’t know is that those same companies are likely making much more extensive use of their own APIs to drive their websites, mobile apps, and other customer-facing products. In our experience, visible public APIs like these are just the tip of the iceberg. Like the large underwater mass of an iceberg, most APIs are private and imperceptible, internal to companies, used by staff and by partners with contractual agreements. This use of APIs is what is really driving the API revolution. Do not limit your thinking about the ways APIs can be used to public examples like the App Store. Partner and internal use of APIs is often more valuable.

Much of the discussion of APIs assumes that they must be open to the public to be of value. This is not the case. We believe that private APIs are having a transformational impact on most companies, in many cases much more so than public APIs.

The New York Times API started as a private API and is transforming their business. “The NYT API grew out of a need to make our own internal content management system more accessible so that we could get the most from our content,” said Derek Willis, Newsroom Developer at the Times. “The API offered a way to give more people access to create more interesting pieces. We are the biggest users of our own API, and that’s not by accident. The API helps our business in other ways: creating brand awareness and helping us attract talent. But fundamentally, it helps us do our own jobs better.”

To further frame this discussion, let’s clarify what we mean by public and private. Public means that the API is available to almost anyone with little or no contractual arrangement (beyond agreement to the terms of use) with the API provider. Private APIs are used in a variety of ways, whether to support internal API efforts or a partner’s use of the API. API providers also offer private APIs to large customers with appropriate legal contracts. Private and public really refers to the formality of the business arrangement. It doesn’t refer to the API content nor does it refer to the applications developed using the API.

Finally, public and private APIs are, in the end, still APIs. Often a company will start with a private API and eventually open some or all of it for public access, possibly with additional restrictions. Other times, a company will launch a public API, then realize how important it is for internal development and in the end it is private use, not public use, that provides the real business benefit.

AccuWeather, for example, is well known for providing weather data to the general public, which would lead most to believe that their APIs are public. But remember: the private/public distinction refers to the arrangement with partners, not to the availability of content to end-users. AccuWeather’s API, like other private APIs, can be and is used to offer applications to the general public.

AccuWeather’s API is highly customized for partners; it’s a key differentiator. “We have over 300 variations of our API. This is a result of our company philosophy—custom for the customer, or for each company using the API,” said Chris Patti, director of technology at AccuWeather. “We respond on a dime to customer requests, and it’s a competitive advantage for us. We’ve won contracts by being able to respond to custom requests, like serving data vs. GPS coordinates. This is why customers work with us, because of our creativity and responsiveness.”

API providers often choose to offer different views of business assets internally and externally. Derek Willis said, “We might offer more than one version of an API to support multiple use cases or business models. We might have different API endpoints for different audiences. For example, the public article search may offer only truncated articles while the internal article search API might offer the full text.”

Why Now?

APIs have reached their breakout moment for three reasons:

Process maturity

APIs are not just about technology. As in many business problems, what we really have is a people problem. APIs offer a common pattern to help people to collaborate.

Self-service

Why did open source succeed? Although the availability of source code is often the focus of discussions about the success of open source, the idea of self-service is much more important. Only a tiny percentage of developers wanted to read or modify source code. Instead, open source software displaced commercial software because developers did not have to ask anyone for permission to take the software and run with it. Publishers of APIs learned from open source. A successful API must be available on a self-service basis and be easy to use. Like open source projects, the best APIs have thriving online communities, either internal to the company or in the larger public developer community (or both). In the most successful developer communities, the most active members don’t work for the company that provides the API—rather, they help because the API is critical to what they do and they love helping others see its value.

Technological maturity

Even though technologists have used APIs for decades, few people realize that the explosion of activity going on with Twitter, Netflix, and others online is based on APIs. The end result that people see is a lot of traffic, but it’s not web traffic. It’s API traffic. Companies like Google, Amazon, Twitter, Sears, Alcatel-Lucent, and thousands of others are using APIs to change their businesses.

In brief, tech blogger Robert Scoble summed up where we are now by defining three eras:

• Web 1994 was the “get me a domain and a page” era

• Web 2000 was the “make my pages interactive and put people on it” era

• Web 2010 is the “get rid of pages and glue APIs and people together” era

We believe that this profound shift will continue and that it’s important for you to know more about it. Chapter 2 describes the impetus behind APIs as a business strategy.