Sachin Agarwal's blog post was featured
Should Enterprises Keep Their External APIs Public or Restricted?
Netflix, the poster child for public APIs, recently retired it in favor of restricting access to a limited set of partners. More about Netflix’s decision to retire their public API can be found in Daniel Jacobson’s blog. This was perhaps the right decision for Netflix based on their business model and the type of API adoption they experienced. However, this decision should open up the debate about enterprises taking a second look at their API initiatives and determining the nature of their APIs, i.e. whether to make them public or keep them restricted.The issue is not whether enterprises should embrace API initiatives. APIs are an excellent and proven means for enterprises to open access to their data and services to third parties, developers, partners and internal teams. APIs enable enterprises to adopt new business models and transition to new digital channels, which have proven to be the growth drivers for most business, irrespective of industry or vertical. This discussion should go beyond the API protocols of REST or SOAP, as I believe APIs are at a much higher level than the underlying protocol. You can find my opinion about REST vs. SOAP in my blog from last year.The most famous and talked about APIs are the open APIs (period), like the ones from Facebook, Twitter, Google Maps and, yes, the erstwhile Netflix API. These companies were amongst the first to adopt APIs and were responsible in evangelizing the benefits of APIs to mainstream enterprises. Due to the publicity and the perceived benefits about opening up APIs to a vast community of developers, enterprises were compelled to create open or public APIs without thinking deeply about their effectiveness. To their credit, these enterprises were the early adopters of APIs, both as a technology and as a business model. However, as APIs mature, specific patterns are evolving, which require enterprises to take a serious look at their business model and decide whether to keep their external APIs open or restricted to partners.Public APIs Public or open APIs should be preferred when the service or data being exposed is unique or a differentiator on its own. The API provider should have a differentiated service that potentially few others can provide. There is only one Twitter, for example. The API provider should not be overtly concerned with how or where the data or service is being used. Also, the data or service should not be potentially sensitive and carry information that might be considered too specific or private. The Facebook API, the Weather API or the Google Maps API are perfect examples of open APIs. How developers embed these APIs have little impact on Facebook’s or Google’s core businesses. My examples should not be misconstrued to imply that open APIs should be only used for unprotected data/services. The Facebook API allows access to the users’ own secured feeds, for instance. Yet, the devil is in the details: how is the data being used, and does it comply with the goals of the business? Public data, content or services also make great examples for open APIs, though there might exceptions to those as well.In the case of Netflix, as explained in their blog, it initially made sense to have a public API. They wanted their content to reach as many apps as possible, they were still a relatively small company then (their stock had not yet skyrocketed to its current highs), and at that time they were one of the few that offered digital content through APIs. The content API itself was a differentiator. However, over a period of time, the industry evolved. Several other competitors started providing digital content through APIs, and the real differentiator was not the API, but the user experience that the App itself provided to the end-customer. In my opinion, Netflix decided to retire its public API because it was running into a commodity play where the actual differentiator is total user experience, not the API itself. To control the experience, Netflix had to restrict API access to a limited set of partners, over whom they could have more control.Restricted APIs – aka B2B APIs In cases where business want to open their data and services still but desire to control how it is used or delivered to end-customers, they should go the route of restricted APIs, making them available to only to partners. They could still have a large number of partners, but contracts with partners allow enterprises to retain control in terms of how their “IP’ or “brand” gets externalized. The initial B2B APIs were seen primarily in the financial industry where financial institutions warranted more control on how sensitive financial data was handled and stored in the Apps. They not only selectively provisioned access to the API keys but also approve the Apps before they hit the respective app stores. However, this trend is gradually falling over to other industries where it is only about security, but also about the experience. For instance, connected car manufacturers, while opening up APIs to their car and dashboards, still want to retain the over customer experience, which ultimately will dictate consumer purchasing behaviors.The guidelines above are not universal, but I think will lead enterprises to put a little more thought into the nature of their APIs. I do not want readers to walk away feeling that I have a bias towards B2B APIs, but my tone did have a slight preference towards restricted API, primarily due to the overwhelming exposure that press and evangelists provide to open APIs. I think there are merits to both, and enterprises should decide what suits best for their initiatives, based on their business model and the nature of API maturity their industry is in.Sachin Agarwal is Vice President of Product Marketing at SOA Software. See More