"Apis-a strategy Guide" the first chapter of API opportunities

Translation/Liu Zhongyang

14 with the brothers of the design team to translate the "Apis-a strategy guide", the time of the past nearly two years, two years of the understanding of the API deepened a few, the translation of the things took out to see, the feeling is quite deep, on the one hand is mainly focused on the design work this piece, There are many ideas in the book can not understand, and now look at a lot of clear, on the other hand, the team two years down has a brother changed departments, but also brothers left the company, think of the hard work of the brothers, or to come out to share, the translation in the developer Community Sub-chapters published, Because the content needs to be checked before release, a weekly publication is planned.

Because all are science and engineering background, translation skills and writing skills are still deficient, we try to understand the content of their own words to describe, and the original text may not be able to correspond to the word.

—————————————————————————————————————————————————

The first chapter of API opportunities

Translation: Liu Zhongyang

APIs are an important element in business success and are becoming more and more important. Pioneering companies such as Google, Facebook, Apple and Twitter have shown the public a good technical solution to transform existing business models and create new industries. The main success of these companies is that the API links users, devices, and infrastructure platforms together to promote the business development of the company and connect the companies behind them.

The world is changing, think carefully about these examples:

? Salesforce.com (CRM systems) has built a huge ecosystem of partners by opening core Services to partners and leveraging the innovation and expansion capabilities of partners. The Salesforce API now has more traffic than the Salesforce site. Since the middle of 2011, more than 60% of Salesforce's traffic comes from the API

? Amazon provides the ability to open up its core computing infrastructure with a multitude of APIs through Amazon Web Services (AWS). There are now more broadband users through AWS services than any other online Web service users in the world.

? Twitter is the most obvious example of an entire business based on APIs and a full set of developers and application ecosystems.

? By transmitting streaming media to different devices, Netflix has rewritten the way we watch movies and TV shows, making video rentals, cable TV and other related industries subversive. And the open API allows Netflix to support these disparate devices in a very economical way.

? The engineering culture of NPR's digital media sector has been injected into the API (open concept). APIs drive websites, mobile apps, and other forms of program distribution and collaboration. The API also changes the way NPR is connected to its member stations and how they share content with them.

Think about the industry trends.

? Smartphone sales overtook new PC sales in early 2011, and Morgan Stanley predicts that by the end of 2012, the number of networked mobile devices will surpass that of PCs. CTIA (Wireless Industry Association) has confirmed that the number of wireless devices in the United States more than people.

? Analysts are racing to predict how many mobile devices will be available in the future. The GSM association predicts that by 2020 there will be 20 billion online mobile devices, with Ericsson CEO Mr Vestberg (Hans Vestberg) predicting 50 billion. At the same time, Cisco's senior vice president of the emerging Technology group, Marthin De Beershuo, predicts the target will exceed 1 trillion by 2020.

? Cisco predicts that by 2015 years, Internet traffic generated by personal computers will continue to grow by 33% per cent a year, but that traffic generated through non-personal computer devices will increase by more than one.

? At the time this article was written, Facebook accounted for more than 25% of Internet page views, and its APIs were driving the Facebook product and its entire ecosystem.

? In the US prime time, over 30% of internet traffic comes from Netflix streaming data, which is distributed and managed through the Netflix API.

These statistics not only indicate the explosion of the entire Internet traffic, but also indicate a significant change in traffic distribution to mobile applications and devices. Looking at these accelerating trends, it's not hard to imagine that the API is likely to be the engine of your Internet traffic for a few years.

Why do we write this book ?

As the author of this book, we understand the subject from the actual combat experience.

Daniel Jacobson,one of the three authors of this book , led the development of NPR's content management system and extracted APIs from the system. The NPR API is now at the heart of the NPR digital distribution strategy, transforming the capabilities of NPR to audiences using different platforms.

Today, Daniel leads the development of Netflix's API,API strategy as a key route for Netflix to drive streaming services. With this service Netflix has the ability to deliver a rich video experience to hundreds of devices, and significantly improve the efficiency of developing new features and delivering them to new devices. With this project, Netflix users have grown dramatically over the next year, with API visits growing from less than 1 billion requests a month to 1 billion requests per day.

Greg Brail(one of the three authors of this book) wrote a book based primarily on his experience as CTO at Apigee, where he helped other companies achieve a large number of API projects. As CTO, he also drew on the wisdom of the Apigee team to complete the book, Apigee's team approached hundreds of developers and learned a lot from the API projects of hundreds of companies.

We write this book to help people understand the potential of the API. We want you to go deep in and create an API carefully. This book is not a programming manual, but a best practice, and you need to understand the opportunities and strategic issues associated with creating an API.

The book will also introduce the broad opportunities of APIs to executives and technicians. To be sure, the API includes a large number of technical elements, and often overlooked is its impact on the business.

This book is about how to consider the API from a business perspective and how to make the API have a positive impact on your business.

We also want to tell you what you need to know when you decide to develop an API. What does it mean to provide an API? Not only from a technical point of view, but also from the business strategy, legal and licensing considerations, and need to consider the relationship with partners and so on.

What we want to illustrate is that the API is having a profound impact on the world's industries, and now is the time to take action.

Unlike many other discussions that focus only on the open APIs of big internet companies, this book also emphasizes the application of proprietary APIs, which we believe will have a greater impact than the many open API projects you often see.

As the author of this book, we must focus on both technical and business content. To do this, we want to educate managers and technicians with innovative ideas about how to incorporate APIs into their business contexts.

In this book, we will discuss:

? Business Opportunities for APIs

? Some companies use APIs to change their business, and even in some cases change their industry examples

? API business model

? What an API value chain looks like and how to open a different value chain

? Develop your API policy considerations, answer related (questions) and objections

? API design issues, especially how to make it easier for developers to choose

? How to handle security issues with the API, including OAuth issues

? Legal issues with the operation of an API business, including privacy and personal data (use) rights issues

? APIs for large-scale application considerations

? How to look at indicators, how to measure your API program

? Participate in developers (discussions) and build community-driven (developers) to use your API "

In short, this book provides an idea to change your business through the API.

Reader object of the book

There are some related books on API technology, including rest, OAuth, XML, JSON, and so on. This book is not intended to compete with these books (technically). In fact, it is almost impossible to understand the API without delving into the technical approach, and this book is not for technical experts who build APIs or use APIs directly. Rather, the book is written specifically for those who need to strategically decide whether they need an API to promote their company.

The book's target audience includes C-level executives, business development teams, product managers, and technology evangelists. Of course, this book audience can also include many higher level technical experts.

What is an API

The API is an abbreviation for the application Programming Interface (Application programming Interface). API as an Access portal for developers, partners, or third-party developers within the company to access data and services to quickly build applications such as iphone apps. Twitter and Facebook's API are all well-known examples. The API can also be divided into APIs that are open to all developers, APIs that are open only to some partners, and APIs that are only available to internal use to help the business run better and facilitate collaboration between teams.

API is inherently a specification. With such a specification guarantee, developers are attracted to and use the API because they know they can rely on it. The specification increases the developer's confidence in the API, which increases the use of the API. Because the specification documents the definition of the interface, clarifies the consistency of the interface, and makes the evolution and change of the interface predictable, this makes communication between the producer and the consumer of the API more efficient,

What's the difference between an API and a website

There is a very big difference between API and website, and the way to provide information is to be taken.

The company publishes information to the world for people to use. The site has no explicit specifications or structural requirements on how to use the content. If the content on the site changes, new visitors are accessing the new content. Their browsers are not affected and any changes are visible to the user. If you design your site, the only thing that is affected is the people who are accustomed to the content in a specific way.

Humans have a strong ability to match visual images, and we can quickly adapt to new designs and find what we need. So when a user's favorite site is redesigned, users may complain, but eventually they will adapt.

The API is very different, because the API is a specification, and the program is developed based on this specification. The program is not as flexible as humans, and its least adept is pattern matching. If you change any point in the API specification, the effect on the upper application may be a stone that stirs up thousands of waves.

Our definition of the API

Technical definition: API is a way of "communicating" between two computer applications, based on the network (mainly the Internet), using the language they can understand together.

To follow the specification, the API means:

? The API provider describes in detail what functionality the API will provide.

? The API provider describes when the feature is available and when it may change and is no longer compatible with the original functionality

? The API provider should describe additional technical constraints in the API, such as access speed (frequency) limits, such as the number of times a particular application or user is using the API within a specified time period (in a given hour, day, or month)

? The API provider should summarize the additional legal or commercial constraints involved in using the API, such as brand limitations, usage types, etc.

? API providers set usage rules, and developers must use APIs based on adherence to these rules.

In addition, the API provider can provide additional tools, such as:

? API access mechanisms and terms of use

? API documentation to help understand the API

? Resources, such as sample programs, developer communities, to guide developers using APIs

? Operational information about the health status and API usage that the API is running "

Remember that the structure of the API is part of the specification. Norms are binding and cannot be arbitrarily changed.

You should treat the API as a software product, consider its version control, and introduce all the new features in a step-up, progressive fashion.

A balance should be found between supporting the existing baseline and maintaining the necessary evolution so that your API can evolve with your business while following its development plan.

This does not mean that the API can never be changed. Instead, the API, as an online product, can be constantly changed to meet the needs of the business or serve the current business to maximize business efficiency. But these are just implementation-level changes, not interfaces. If done correctly, the API implementation can be changed every day, even more frequently, but the interface is always consistent.

But there's a lot of similarities between the API and the website.

The API, like a website, needs to be 24*7 and run uninterrupted 365 days a year. Developers, like site users, do not have the patience to accept "scheduled downtime maintenance every Saturday". All of these instructions building an API on an existing enterprise technology infrastructure will be a challenge because the business system is often designed as a system with a certain operating cycle, which is closed after one cycle, until the next day (such as the banking system), and the API is not designed to do so.

A successful website can be continuously updated, changing its page design, and fine-tuning features. This ongoing update is possible because the site is an entity that is online and does not need to be modified by the client, and does not require a software update by a generic user after the update.

The API does not differ much in this regard. Assuming your API retains a back-to-compatibility capability, the API will not affect existing client programs while introducing new features and changing existing functionality implementations. As long as you insist that developers use it in accordance with the API specification, the evolution of the API can follow the "network plan" rather than the "Enterprise IT Timeline" (Translator note: The API can change on a "web Shedule" rather than on a "enter Prise IT Schedule ". Personally, we only need to upgrade the API on the Web, without the need to upgrade the corporate IT system that uses these APIs. This will enable a better and more user-used API project to evolve.

In fact, you can drive API and website evolution by analyzing the behavior of applications and end users. For both, good design and product management teams constantly examine and analyze data to see which sites or APIs are successful and which fail. These results should be incorporated into regular development iterations to build a more powerful API or Web site over time.

who will use the API

We call the company or organization that provides the API the API provider. This book is intended primarily for API providers (or those that are considering providing APIs).

We call developers who build apps using the API. Indeed, many people are interested in your API, including business owners, marketers, executives, etc., but the people who end up using the API to build applications are developers. The developer is the main audience for the API.

We call people who use developer apps as users. They are the second audience for your API and the people who often drive your API decisions, and depending on the features available in your API, you may have special issues to declare, such as copyright, legal use, and so on, which are relevant to them.

Types of APIs

We see two types of APIs: private and open. No matter what you hear in the media, the private API is more common. You know the world is now using the Facebook and Twitter APIs. What you may not know is that these companies are making extensive use of their APIs to build their websites, mobile apps, and other users ' products. Our experience tells us that these common public APIs are just the tip of the iceberg. Like underwater icebergs, most APIs are private and hard to perceive, and these private APIs are used by employees and partners within the company as a standard protocol. The use of private APIs really drives the API revolution. Don't limit your understanding of how APIs are used because public APIs are applied to the Apple Store example, and the partners and internally used APIs are often more valuable.

Most of the discussion about APIs is the assumption that APIs must be open to the public to be valuable. Not really. We believe that private APIs are having a revolutionary impact on most companies, and in many cases they are much more impacted than public APIs.

The New York Times API began to be used as a private API, gradually changing their business. "The New York Times API comes from our desire to make internal content management systems easier to use, so we can get more of what we want." "The New York Times editorial developer, Derrickwellis, said. "API allows more people to access and create interesting content, we are the largest user of our own API, but this is not accidental." APIs can help us grow our business in other ways: Creating brand awareness and helping us attract talent. But fundamentally, it helps us to do our jobs better. ”

Let's discuss this topic further and clarify what we mean by public APIs and private APIs. Public APIs are APIs that everyone can use without the API provider authorizing (exceeding the terms of the agreement). Private APIs are used in many ways to support internal API work or partner use. The API provider should also provide the appropriate legal terms to large customers who use the private API. Whether the API is private or public is primarily related to the main business, neither should reference the API's own content nor should it refer to applications developed using the API.

The public and private APIs are ultimately still APIs. Typically a company will start with the development of a private API and eventually open it partially or completely, and may set some additional restrictions for public use. In another case, the company will launch a public API, and then realize that internal development is more important and privatized, which ultimately gives the company real business benefits.

For example, AccuWeather is known for providing weather data to the public, which makes most people think their API is public. But keep in mind that the difference between a private/public API is that it's a contract with a partner, not something that the end user can get. Like other private APIs, AccuWeather's API is used to deliver applications to the public.

For partners, the AccuWeather API is highly customizable, which is a key differentiator. "Our API has more than 300 different versions," said Chris Pati, AccuWeather technical director. This is the result of our business being customized for each customer, each company that uses our API. We respond quickly to customer needs, which is our competitive advantage. We are able to respond to custom requirements so we have won many contracts, such as providing data services and GPS positioning capabilities. Because of our creativity and responsiveness, our clients work with us. ”

API providers often choose from both internal and external perspectives to present their business assets. Derrick Willis said: "We can provide multiple versions of the API to support multiple usage scenarios or business models. We can have different API patterns for different user services. For example, the public document search API can only provide fragments of literature, while the internal literature search API provides full documentation. ”

why now?

The API has come to a breakthrough, for three reasons:

? Process Maturity Level

API is more than technology. Many of the business problems we encounter are just personal issues. The API provides a common pattern to help people collaborate. "

? Self-Service

Why are open source projects successful? Although it is considered in many discussions that the source code is the key to success in open software, another view is that self-service is more important. Only a small percentage of developers want to read or modify the source code. In contrast, open source code software can replace commercial software because developers can get the software and use it without having to get a license. API Publishers Learn from open source software. A successful API must be self-serving based and easy to use.

As with open source projects, the best APIs have high-popularity online communities, both within the company and in the large open developer community (or both).

In the most successful developer community, the most active members are not working for the company that provides the API, but they want to help the API, because the API is critical to what they do, and they love to discover the value of the API by helping others. "

? Technical Maturity Level

For decades, despite the constant use of APIs by technicians, few people realized that it was because of the APIs that they continued to burst out like Twitter, Netflix and other Web services.

Eventually people see a huge amount of traffic, but it's not network traffic, but API access.

Companies like Google, Amazon, Twitter, Sears, alcatel-lucent and thousands of companies are using APIs to change their business. "

In short, tech blog author Robert Scoble A three-time definition of what we're in now:

? The 1994 network is the era of "give me an address and a page"

? The 2000 network is the "Let my pages interact with people" era

? The 2010 network is "get rid of the page, let the API connect with people" era

We believe that this far-reaching transformation will continue and that it is important to know more about you. The second chapter will describe what kind of impetus the API will have as a business strategy.

(For more information about Huawei, please follow Huawei's developer community, Huawei's own open door: http://developer.huawei.com/cn/ict/, don't ask me what I call, others call me Lei Feng )

"Apis-a strategy Guide" the first chapter of API opportunities