11436 SSO

API Best Practices: Learnings from Beyond Silicon Valley

The Netflix pattern isn't always the right one
Apr 05, 2016

I’m continually surprised by how often Netflix is cited as the exemplar of best practices for implementing APIs. Netflix’s Dan Jacobson, with whom we’ve worked in the past, has blogged about it, and he has clearly articulated that there are at least two layers of APIs: one with fidelity to the systems of record (SORs), and one with fidelity to the application (and maybe to the device) that he calls “experience APIs.”

In Dan’s world, one can get hundreds of experience APIs if one has hundreds of different devices and applications—yet all of them may call only a dozen or so SOR APIs.

Such an approach delivers on performance and separation of concerns. The developers creating APIs on the SORs are focused on common data models and reuse. The developers focused on building applications might want to avoid extra network calls, so they implement experience APIs that are called once by the app, but, in the API (orchestration) layer, they in turn call one or more SOR APIs.

Many of us like this approach. In fact, Apigee is very often used by our customers to implement these two layers. We have counted at least 18 (about 10%) of our cloud customers who implement such a strategy. Apigee makes this very easy. Efficient proxy chaining and lightweight orchestration make Apigee the right layer to implement this separation of concern.  

So Netflix offers a good pattern, and organizations of all shapes and sizes can easily build that pattern in their API layer using Apigee.

Caveat emptor, though. We should always be careful about over-indexing Silicon Valley patterns.

When it comes to APIs, we’ve seen that the typical organization has:

  • an organizational complexity that far exceeds that of most Silicon Valley companies
  • legacy SORs that present both an opportunity (millions of customers, thousands of stores, the focus on customer relationships) as well as a curse (starting from scratch is not an option)
  • no plethora of devices, so no requirement for high-fidelity experience APIs
  • complex API styles—SOAP, REST, JMX, you name it
  • heterogeneity of cloud and data center deployments
  • a smaller IT budget than technology-centric Silicon Valley companies (my colleagues Ed Anuff and Brian Pagano recently did a fantastic webinar comparing the IT spends in the context of build vs. buy—you should check it out)

All of us, every day, have to decide what to learn from others, and how to implement these lessons. Apigee incorporates the learnings—from Silicon Valley companies, but also from working with hundreds of enterprises that look nothing like Netflix. Our learnings show up in our products (we released proxy chaining in our latest release, for example) so if you go with Apigee, we will continuously provide the shortest path to best practices from a broad enterprise landscape.

You're not alone in this journey, and Netflix isn't the only shining beacon out there.

Creating World-Class Developer Experiences