Over at APIevangelist.com, the site's editor Kin Lane has published a blog -- one that I disagree with --- that insults the tech blogosphere in the same breath that it claims there will be no such thing as public vs. private APIs. In that blog, Lane writes:
"the concept of public and private doesn't exist. This is a reality that plays out in conversations between people who don’t fully understand the world of API management—aka the tech blogosphere. If it has an http:// in front of the address, it is a public API—sorry."
ProgrammableWeb does not subscribe to the idea that we should retire the distinction between public vs. private APIs. The nomenclature of "public APIs" vs. "private APIs" are, in fact, a critical part of the conversation that's playing out everywhere in the API economy for two reasons.
First, as "API language" goes, both terms are commonly interpreted by API stakeholders to primarily imply a business decision when engaged in a conversation about API strategy. In other words, when one person says "we'll make that API private and that other one public," everyone in that conversation knows what that person means. When developers hear that an API is private vs. public, they also know what that means. In both groups, there might be some newcomers who don't get it, but it isn't long before they're up to speed.
Second, but equally important is when businesses and API stakeholders are communicating requirements to API management solution providers. The public vs. private distinction is not only a common language, it will impact solution selection (based on public/private capabilities, cost, buyer comfort level, etc.) as well as implementation specifics.
It's About The Target Developer
Across the API economy, various API stakeholders are charged with aligning their API strategies with their business strategies. Security-wise, those business decisions will often dictate certain technological choices and best practices across the entire IT estate. But picking between public vs. private is primarily not a technological choice. It's a business choice along the lines of Netflix's Daniel Jacobson's often-referenced explanation of LSUDs (Large Sets of Unknown Developers) vs. SSKDs (Small Sets of Known Developers). For example, Amazon's IaaS APIs are broadly available to anyone in the public (aka: LSUD) on a self-serve basis and are, from a business perspective, considered to be public APIs. The term "public" is not used to communicate a technological choice (as in "Let's make it HTTP"), but rather a business decision regarding a target of LSUDs that most closely aligns with Amazon's business strategy and future ambitions.
Although they are based on HTTP (the core protocol of the World Wide Web), and available by way of the Internet, Netflix's and many Walgreen's APIs (eg: the Walgreens Balance Rewards API) are considered to be private in that they are only available to approved partners (aka: SSKDs). They are private programs in the way that some country clubs, though accessible by way of public roads, are private. It's a business model descriptor that is broadly understood by all stakeholders in the country club market in a way that facilitates a common understanding across all sorts of conversations. Extending the country club metaphor a bit further, virtually no one says that a private country club is actually a public country club with stricter security because its entrance is on a public road. To the country club, the word "private" is both a business choice and a designation. To the market, the world "private" as it applies to country clubs communicates "exclusivity." When, for example, ESPN announced that "we have made the difficult decision to discontinue our public APIs" under the headline "Public API Retirement," the entire industry knew what ESPN meant by the word "public." The same is true for ESPN's elaboration that included the phrase "public API keys" (also equally and widely understood): "Effective today, we will no longer be issuing public API keys."
(Continued on page 2)