Public APIs Are Tough When You Are In A Tightly Controlled Industry
08 Aug 2014
ESPN just announced that they will no longer be accepting registrations for public API keys, and discontinuing all of their public APIs. I saw a few enraged comments on the Twitterz when I originally tweeted out the story, and also saw a couple of people compare it to the recent Netflix API deprecation.
In reality I don't think the shuttering of the public ESPN API, or the Netflix API is a reflection on the viability of APIs, steering clear of the usual API FUD that APIs are forever, wait no…they can go away at any time! I think the decision to shutter the ESPN API is due to lack of vision, outreach, and the establishment of the vital developer feedback loops that are necessary to make APIs successful, but most importantly they failed to understand the challenges faced when deploying APIs in a tightly controlled industry.
Doing public APIs in tightly controlled spaces like the movie and sports industry has to be tough. Both to these spaces have built their empires on tightly controlling the content, messaging, distribution, branding, and other elements—which are all things that work against the ethos of a successful public API strategy. In my mind it shows that APIs aren’t really the thing we all claim they are, it is everything that comes bundled the API, and a company's willingness to evolve.
I’m sure we'll see waves of other companies, who come from legacy industries like movies, sports, publishing, television, and other similar sectors, try APIs, thinking they will be a technological silver bullet, in coming years who also neglect to pay attention to the business and politics of APIs that will provide essential building blocks that support the technology.
There are plenty of lessons to be learned from both ESPN and Netflix, but two that stand out for me, is the importance of understanding the entire lifecycle of the resources you are making available, and the value of having a robust API service composition and API access tiers, that sensibly serve internal, partner, and in some(not all) cases public API consumers.