This post originally appeared on the Netflix Tech Blog on July 9, 2012.

As I discussed in my recent blog post on ProgrammableWeb.com, Netflix has found substantial limitations in the traditional one-size-fits-all (OSFA) REST API approach. As a result, we have moved to a new, fully customizable API. The basis for our decision is that Netflix’s streaming service is available on more than 800 different device types, almost all of which receive their content from our private APIs. In our experience, we have realized that supporting these myriad device types with an OSFA API, while successful, is not optimal for the API team, the UI teams or Netflix streaming customers. And given that the key audiences for the API are a small group of known developers to which the API team is very close (i.e., mostly internal Netflix UI development teams), we have evolved our API into a platform for API development. Supporting this platform are a few key philosophies, each of which is instrumental in the design of our new system. These philosophies are as follows:

• Embrace the Differences of the Devices
• Separate Content Gathering from Content Formatting/Delivery
• Redefine the Border Between “Client” and “Server”
• Distribute Innovation

I will go into more detail below about each of these, including our implementation and what the benefits (and potential detriments) are of this approach. However, each philosophy reflects our top-level goal: to provide whatever is best for the Netflix customer. If we can improve the interaction between the API and our UIs, we have a better chance of making more of our customers happier.

Now, the philosophies…

Embrace the Differences of the Devices

The key driver for this redesigned API is the fact that there are a range of differences across the 800+ device types that we support. Most APIs (including the REST API that Netflix has been using since 2008) treat these devices the same, in a generic way, to make the server-side implementations more efficient. And there is good reason for this approach. Providing an OSFA API allows the API team to maintain a solid contract with a wide range of API consumers because the API team is setting the rules for everyone to follow.

While effective, the problem with the OSFA approach is that its emphasis is to make it convenient for the API provider, not the API consumer. Accordingly, OSFA is ignoring the differences of these devices; the differences that allow us to more optimally take advantage of the rich features offered on each. To give you an idea of these differences, devices may differ on:

• Memory capacity or processing power, potentially modifying how much content it can manage at a given time
• Requirements for distinct markup formats and broader device proliferation increases the likelihood of this
• Document models, some devices may perform better with flatter models, others with more hierarchical
• Screen real estate which may impact the content elements that are needed
• Document delivery, some performing better with bits streamed across HTTP rather than delivered as a complete document
• User interactions, which could influence the metadata fields, delivery method, interaction model, etc.

Our new model is designed to cut against the OSFA paradigm and embrace the differences across devices while supporting those differences equally. To achieve this, our API development platform allows each UI team to create customized endpoints. So the request/response model can be optimized for each team’s UIs to account for unique or divergent device requirements. To support the variability in our request/response model, we need a different kind of architecture, which takes us to the next philosophy…

Separate Content Gathering from Content Formatting/Delivery

In many OSFA implementations, the API is the engine that retrieves the content from the source(s), prepares that payload, and then ultimately delivers it. Historically, this implementation is also how the Netflix REST API has operated, which is loosely represented by the following image:

The above diagram shows a rainbow of colors roughly representing some of the different requests needed for the PS3, as an example, to start the Netflix experience. Other UIs will have a similar set of interactions against the OSFA REST API given that they are all required by the API to adhere to roughly the same set of rules. Inside the REST API is the engine that performs the gathering, preparation and delivery of the content (indifferent to which UI made the request).

Our new API has departed from the OSFA API model towards one that enables fine-grained customizations without compromising overall system manageability. To achieve this model, our new architecture clearly separates the operations of content gathering from content formatting and delivery. The following diagram represents this modified architecture:

In this new model, the UIs make a single request to a custom endpoint that is designed to specifically handle that request. Behind the endpoint is a handler that parses the request and calls the Java API, which gathers the content by calling back to a range of dependent services. We will discuss in later posts how we do this, particularly in how we parse the requests, trigger calls to dependencies, handle concurrency, support fallbacks, as well as other techniques we use to ensure optimized and accurate gathering of the content. For now, though, I will just say that the content gathering from the Java API is generic and independent of destination, just like the OSFA approach.

After the content has been gathered, however, it is handed off to the formatting and delivery engines which sit on top of the Java API on the server. The diagram represents this layer by showing an array of different devices resting on top of the Java API, each of which corresponds to the custom endpoints for a given UI and/or set of devices. The custom endpoints, as mentioned earlier, support optimized request/response handling for that device, which takes us to the next philosophy…

Redefine the Border Between “Client” and “Server”

The traditional definition of “client code” is all code that lives on a given device or UI. “Server code” is typically defined as the code that resides on the server. The divide between the two is the network border. This is often the case for REST APIs and that border is where the contract between the API provider and API consumer is engaged, as was the case for Netflix’s REST API, as shown below:

In our new approach, we are pushing this border back to the server, and with it goes a substantial portion of the UI-specific content processing. All of the code on the device is still considered client code, but some client code now resides on the server. In essence, the client code on the device makes a network call back to a dedicated client adapter that resides on the server behind the custom endpoint. Once back on the server, the adapter (currently written in Groovy) explodes that request out to a series of server-side calls that get the corresponding content (in some cases, roughly the same rainbow of requests that would be handled across HTTP in our old REST API). At that point, the Java APIs perform their content gathering functions and deliver the requested content back to the adapter. Once the adapter has some or all of its content, the adapter processes it for delivery, which includes pruning out unwanted fields, error handling and retries, formatting the response, and delivering the document header and body. All of this processing is custom to the specific UI. This new definition of client/server is represented in the following diagram:

There are two major aspects to this change. First, it allows for more efficient interactions between the device and the server since most calls that otherwise would be going across the network can be handled on the server. Of course, network calls are the most expensive part of the transaction, so reducing the number of network requests improves performance, in some cases by several seconds. The second key component leads us to the final (and perhaps most important) philosophy to this approach, which is the distribution of the work for building out the optimized adapters.

Distribute Innovation

One expected critique with this approach is that as we add more devices and build more UIs for A/B and multivariate tests, there will undoubtedly be myriad adapters needed to support all of these distinct request profiles. How can we innovate rapidly and support such a diverse (and growing) set of interactions? It is critical for us to support the custom adapters, but it is equally important for us to maintain a high rate of innovation across these UIs and devices.

As described above, pushing some of the client code back to the servers and providing custom endpoints gives us the opportunity to distribute the API development to the UI teams. We are able to do this because the consumers of this private API are the Netflix UI and device teams. Given that the UI teams can create and modify their own adapter code (potentially without any intervention or involvement from the API team), they can be much more nimble in their development. In other words, as long as the content is available in the Java API, the UI teams can change the code that lives on the device to support the user experience and at the same time change the adapter code to deliver the payload needed for that experience. They are no longer bound by server teams dictating the rules and/or being a bottleneck for their development. API innovation is now in the hands of the UI teams! Moreover, because these adapters are isolated from each other, this approach also diminishes the risk of harming other device implementations with tactical changes in their device-specific APIs.

Of course, one drawback to this is that UI teams are often more skilled in technologies like HTML5, CSS3, JavaScript, etc. In this system, they now need to learn server-side technologies and techniques. So far, however, this has been a relatively small issue, especially since our engineering culture is to hire very strong, senior-level engineers who are adaptable, curious and passionate about learning and implementing these kinds of solutions. Another concern is that because the UI teams are implementing server-side adapters, they have the potential to bring down the servers through infinite loops or other processes that are resource intensive. To offset this, we are working on scrubbing engines that will hopefully minimize the likelihood of such mistakes. That said, in the OSFA world, code on the device can just as easily DDOS the server, it is just potentially a bigger problem if it runs on the server.

Example of how this new system works:

1. A device, such as the PS3, makes a single request across the network to load the home screen (This code is written and supported by the PS3 UI team.
2. A Groovy adapter receives and parses the PS3 request (PS3 UI team)
3. The adapter explodes that one request into many requests that call the Java API to (PS3 UI team)
4. Each Java API calls back to a dependent service, concurrently when appropriate, to gather the content needed for that sub-request (API team)
5. In the Java API, if a dependent service unavailable or returns a 4xx or 5xx, the Java API returns a fallback and/or an error code to the adapter (API team)
6. Successful Java API transactions then return the content back to the adapter when each thread has completed (API team)
7. The adapter can handle the responses from each thread progressively or all together, depending on how the UI team wants to handle it (PS3 UI team)
8. The adapter then manipulates the content, retrieves the wanted (and prunes out the unwanted) elements, handle errors, etc. (PS3 UI team)
9. The adapter formats the response in preparation for delivery back across the network to the PS3, which includes everything needed for the PS3 home screen in the single payload (PS3 UI team)
10. The adapter finally handles the delivery of the payload across the network (PS3 UI team)
11. The device will then parse this optimized response and populate the UI (PS3 UI team)

We are still in the early stages of this new system. Some of our devices have fully migrated over to it, others are split between it and the REST API, and others are just getting their feet wet. In upcoming posts, we will share more about the deeper technical aspects of the system, including the way we handle concurrency, how we manage the adapters, the interaction between the adapters and the Java API, our Groovy implementation, error handling, etc. We will also continue to share the evolution of this system as we learn more about it.

Below are the slides from my presentation to the engineering team at PayPal. This presentation discusses the history and future of the Netflix API. It also goes into API design principles as well as concepts behind system scalability and resiliency.

This is link to the video and slides from a presentation that I gave at QCon in San Francisco on April 30, 2012

Daniel Jacobson covers the history of Netflix’s APIs, adaptation for the cloud, development and testing, resiliency, and the future of their APIs.

This article first appeared on Forbes on February 12, 2012

APIs: A Strategy Guide

For most of the past year, I have worked with two brilliant experts on APIs, Daniel Jacobson, at Netflix and Greg Brail, CTO of Apigee, to create a book that clearly explains the value of APIs. In researching the book, APIs: A Strategy Guide, we talked to dozens of other smart people who had led the creation of APIs for both internal and external use.

One of the most striking findings was how often API programs were started in secret, nurtured by the true believers in a clandestine way, slipped into production, and then brought to the awareness of senior management after the API was shown to be a success.

This pattern is understandable but ridiculous. Our book is an attempt to obviate this pattern by providing a top-to-bottom reference for people who want to understand the business value of APIs. But we are not naive. We know that the most likely people to read our book are also true believers and innovators who are already open to new ideas. The trick to accelerating the adoption of APIs and reaping the massive value they can create, is to convince skeptics. At some point, that means convincing the CEO, who, if sold on the idea, can bring all the resources of the organization to bear. APIs have been proven over and over to be a transformative force. It is time for technology leaders to force the issue. So, get yourself a meeting with your CEO and have a conversation along the following lines.

The Business Basics of APIs

When a CEO looks at the calendar entry for your meeting, he or she will likely think, “My god, this seems a bit technical for me. Shouldn’t the CIO or CTO be handling this?” So your first job is to make sure that the CEO understands that APIs are huge channels for business. Start the conversation by pointing out these facts:

APIs are not experimental: More than half of all the traffic to major companies like Twitter and eBay come through APIs

• APIs are channel to new customers and markets: APIs used externally unlock the power of partners to use business assets to extend the reach of your products or services to customers and markets you may not easily reach.
• APIs can be private: Much of the talk about APIs emphasizes their public use. Internal APIs should be part of every companies IT strategy.
• APIs promote innovation: Through an API, people who are passionate about a problem can solve it on their own.
• APIs are a better way to organize IT: APIs used internally can accelerate innovation by allowing everyone in a company to use each others assets without having to wait around for permission.
• APIs are not only for huge companies: The technology is standardized and able to be used by companies of all sizes.
• APIs create a path to lots of Apps: Apps are powered by APIs. When developers are motivated, they can use APIs and combinations of APIs to create new experiences for end users.
• APIs to create lots of apps that can lead to lots of customers: Apps are going to be a crucial channel in the next 10 years. There will be trillions of apps in the next decade vs.a billion web browsers in the last.

Then point the CTO to the post by Google engineer and Amazon alumnus Steve Yegge, that points out that APIs are so important to Amazon CEO Jeff Bezos that he threatened to fire anyone who didn’t expose their assets through APIs.

APIs from Twitter, Amazon, Google, and Facebook have been used to create thousands of applications. These victories are being followed by APIs from AT&T, Sears, E*Trade, Alcatel-Lucent, Accuweather, and hundreds of other companies. Point the CEO to the research from John Musser, founder of ProgrammableWeb.com, a site that tracks the growth of APIs.

At this point if your CEO isn’t interested, then there’s not much you can do.

However, the next question your CEO will likely have is, “What is an API?”

Drawing this simple graphic is a good way to start:

API Value Chain

Explain that APIs are a simple way to provide access to some type of business assets. The business asset can be information itself, information about a product or service, or direct access to the product or service.

Point out that to make an API successful, everyone in the value chain must benefit. Make sure you convey you are not suggesting that if you build an API, the world will come rushing to use it.

The value chain takes many forms. The organization that owns the business asset may or may not be the same as the organization that builds the APIs. Different people or organizations may build, distribute, and market the applications. At the end of the chain are end users who gets the benefit of the business asset. Often, many APIs are used to create a new experience for end users.

Finding your API Value Proposition

If you are getting anywhere with your conversation, your CEO will likely get impatient with the technology and want to know the payoff for your company. He or she may say, “Great, APIs are a big deal, but what does that have to do with us?”

Here’s where you need to come armed with some sort of experiment that you want to get support for. One of the best ways to start is with an internal use of APIs. A key point of our book, one tirelessly championed by Daniel Jacobson, is that internal use of APIs is going to have the largest impact for most businesses. Remember, Amazon’s Jeff Bezos was going to fire people if they didn’t create internal APIs.

So, what are the business assets? Usually information that would benefit the company if more people had it in their hands. Look at the backlog of requests to IT. Is there an API that could take several items off the list? Have this in mind.

It is much better to build skills internally and master the design, development, testing, and operational processes before putting an API in public. That said, with careful planning and a clear value proposition, it is possible to have your first API be a public one, especially if you are following a well-established method of using APIs.

If you do start with an external public API, make sure you have a long testing cycle and flesh out all business and legal concerns before launching. I recently talked about API design and development with Byron Sebastion of Heroku, the Ruby platform for development that was purchased by Salesforce.com in 2010. He said that all of their APIs are first used extensively internally before going through a long public beta test. “When you launch an API, you want to make sure you are confident it is right, because people will rely on it,” Sebastian said.

At this point, I hope you are successful, because then you will need to answer questions about business models, design, engineering, operations, and marketing, all of which are covered in our book.

This article covers one way to go about educating a CEO about APIs. If you have other approaches, please send them along.

Also, we are going to be expanding the book several times this year. If you have a good example of how APIs have been successful for your organization, please reach out to me.

Dan Woods is CTO and editor of CITO Research, a firm focused on advancing the craft of technology leadership. He consults for many of the companies he writes about. For more stories about how CIOs and CTOs can grow visit CITOResearch.com.

This article originally posted by Scott Fulton on ReadWriteWeb on February 3, 2012 as Part II in a series. Part I can be found here.

What we today call the “mobile app” could, in a very short period of time, become known as the portable app, or just the “app.” It tends to use such a simple and straightforward model of interaction that people are starting to prefer using their smartphones for certain tasks, even when their PCs are right in front of them. By this time next year, portable apps originally designed for use on smartphones and tablets may be running on laptops.

The extent to which this changes everything is a topic that no one, not even ReadWriteWeb, has fully fathomed. The Web as we have come to know it will be affected significantly. What users have come to know as Web sites will be willingly and eagerly substituted with Web apps. In Part 2 of our interview with the co-author of APIs: A Strategy Guide, Netflix lead API engineer Daniel Jacobson tells us the one huge difference between an app and a site involves the extent to which they rely on an API. It is part of every app’s DNA.

The First, Painful Steps Toward Multi-Platform

In 2002, as you learned from part 1 of our RWW interview last week, when Jacobson was with NPR, he helped make a critical decision about its information infrastructure, the implications of which his team had not foreseen: “Literally the first thing that we did,” he tells RWW, “is, we built the API and we put the Web site on top of it. So the Web site runs off the API. It’s a little bit of a different interaction model; it doesn’t have to go through the authentication and whatever else, in the same way that external apps do.”

That API later gave NPR the freedom to build apps that run outside the browser, and that use that same API in different ways. So when mobile apps were invented, NPR was among the first publishers to be ready for them. When Netflix saw it needed an architecture that enabled it to reach all its users without it being dependent upon the usage model for any one device, including the Web browser, it hired Jacobson to build it.

A 2005 Netflix demo at a Microsoft convention featured one of that company’s program managers at the time, Darryn Dieken, showing then-President Jim Allchin the prospects of using one underlying technology as the foundation for developing a unified product line across different devices. The technology at the time was code-named “Avalon,” and evolved into what we now call Silverlight.

After showing how a Netflix product selector ran outside the browser but through the Web, in a way people had never seen before at that time, Dieken showed essentially the same selector running inside Windows Vista on a tablet PC. From there, he proceeded to show where else folks would eventually find Netflix.

The demo took the audience inside Windows Media Center, which had just been released for Windows XP and was being vastly updated for Vista. The Media Center plug-in used many of the same presentation techniques and concepts as the stand-alone version, demonstrating the benefits of code reuse.

But when the demo turned its attention to Netflix on a Windows Mobile phone, it became painfully obvious that the benefits of client-side code reuse could only go so far. Yes, there was communication taking place between all these different clients and the server. But the way these interactions were happening were based on leveraging Web site-oriented, forms-based submissions that at one level could be described as an API, but failed to be uniform – one API for many platforms.

The goal of any modern API, Dan Jacobson emphasizes, is “to treat any presentation layer the same. So if you have multiple Web sites, like NPR does (they have NPR Music as well as NPR.org), both of those sites run off of the same interaction model through the API. They’re just presentation layers, the same way as mobile app or Google TV or [NPR] Infinite Radio. Users are going to consume new material in any way that they want to, wherever, whenever; and your goal as publisher is to make sure that you have a presentation layer that serves them wherever that is. And in doing so, the easiest way, the most effective way to date is to leverage APIs, and invest a little bit on having the right talent surrounding it.”

“Publish Everywhere” Doesn’t Have to Be Homogenous

Because presentation layers are so different from one another, he goes on, a business can and should nurture teams of developers with the exclusive skillsets that each of those layers needs – for example, Objective-C developers for iPhone apps. There’s no reason why certain teams can’t specialize. Having a single API that addresses each layer in a standard way, he says, provides all your teams with the flexibility they require to take advantage of the platforms on which they’re focused.

This allowance for specialization tends to work itself away from the “one Web” way of thinking, the belief that everything will inevitably merge into HTML5. In professing that API design should not be centered around any one single mode of presentation, lest it eventually become obsolete (among other reasons), Jacobson advises that API designers focus on finding ways to symbolize and encode business interactions, the things that businesses do, not the things that Web sites do. Your goal is not to make the browser more efficient or the user experience more immersive. Leave that to the UX designers. As the API engineer, your goal is to enable business.

“That kind of thinking is fundamentally different than, ‘How do I want to structure my content? Do I need to think about what resources can be broken up in which ways and made available in different ways?’” says Jacobson. “For NPR, for example, there are stories, there are assets, different kinds of things in that system. For Netflix, there are users, catalog items. How do you want to structure that material, both in terms of the resource level as well as items underneath it? What are the rights management concerns that go into this, legal constraints internally about what can be published? For Netflix, what can I show users in Latin America that I can’t show to people in Canada? For NPR, it’s, I’m publishing AP photos; whom can’t I present that to, and whom can I? Those kinds of things are really business-oriented decisions that you can’t just flip a switch and say, ‘Make it happen.’ You need to be very thoughtful about what you’re exposing and to whom, and how you’re going to do it so you can get the maximum effectiveness out of it.”

It is this concept which may outmode, or render obsolete, the traditional notion of the Web site, the notion that something that’s created once and published everywhere (COPE) must always be the same thing. Done properly, Jacobson says, it can and should be integrated with the uniqueness of each device.

“When Web APIs started out, they tended to be more about publishing on all kinds of different platforms. Now I think it’s very much about aggregation, and merging others’ API experiences,” says the Netflix engineer. “One of the interesting things with Netflix, for example: We have branded apps on a wide range of platforms, and if you look at something like AppleTV or Roku or Xbox, or any of these other devices, we’re not the only ones there. There is an aggregation of services where Netflix creates an experience on that platform. We actually integrate with their systems, we’re creating an experience on that site, and then people can access our experience in the way they expect it to be presented.”