Download
Introduction
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
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.
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.
