For fans of HBO’s cultural phenomenon Game of Thrones, you probably remember the recent admonishment Lord Baelish laid on Lady Sansa by simply asking “What did I once tell you about the capital?” In what many hope was the show’s attempt to foreshadow a more empowered, less naive Sansa, she quickly replied “We’re all liars here.”
What does this have to do with monitoring APIs? In a word—everything.
APIs live in a world that in many ways resembles that of Game of Thrones. There are seemingly endless characters and alliances, all vying to separate themselves from the pack and earn your allegiance – but as with any good story about power and struggle it all comes down to whom you can trust.
The last few years have seen APIs take over as THE dominant pieces in Web architecture—evolving from simple solutions that allowed developers to connect disparate applications to the underlying foundations of the applications themselves. This transformation has led to the first true delivery of the Web via real service oriented architecture—and it’s been fun to watch. The aggressive leveraging of APIs for application development has dramatically simplified the build process, enabling developers and businesses to focus more closely on the products they’re creating and the user experiences delivered—and that’s a good thing for everyone.
But before you hit the mead too hard in celebration you need to understand one thing—just like any of the alliances between the various houses of Westeros—blind faith in any one partner is a dangerous proposition; whether it’s the House of Lannister or Google’s OpenID API.
While APIs have ushered in a new era of developer creativity and efficiency the fact remains that they are susceptible to the same performance hiccups and outages as the applications they are being used to create. Several years ago it was rare that an API would power an essential application component—today it’s becoming the norm.
Apple built its smartphone dominance on the slogan “There’s an App for that”—now “There’s an API for that” seems a more appropriate phrase. Today’s Web applications regularly rely on third-party APIs to run everything from checkout processes to the real-time display of sports and weather data—and pretty much everything in between.
This increased reliance on APIs has seen their development become a business in and of itself—something a simple “API Marketplace” Google search will quickly confirm. This sea change is fueling a new collective consciousness in the Web operations community around the role APIs play in overall application performance and the importance of monitoring all the APIs that touch any given application.
The real issue here is the seemingly endless array of API options available to developers when building their applications—and which ones they can trust. There are the APIs created and backed by major Web players like Google, Facebook and Twitter, and then there are the more unique services that solve niche issues like CheapShark—a newer API that tracks the price of PC games on ecommerce sites like Amazon and Steam.
These newcomers and mashups are certainly representative of the innovative, demand-generated nature of emerging API markets—but with little real-world implementation developers should be wary of making them integral components of their apps. Although the U.S. Appellate Court’s recent ruling that APIs are copyrightable may significantly curb the open nature of today’s API economy, the credo at many Web-based businesses will continue to be "innovate or die." The reality is that sometimes the only (i.e. fastest, most cost-effective) way to build an innovative new solution is to leverage some (as of yet) unproven APIs.
But when companies like Facebook and Google are still experiencing API outages it’s a given that these new upstarts are equally, if not more, prone to their own downtime—which is why a robust approach to API monitoring has become a crucial piece of modern application performance management. While many organizations have already recognized the value of API monitoring (See this SmartBear Raymond James case study), too often API performance considerations are limited to initial proof of concept, functional testing, and (maybe) load testing.
I’m not going to spend the next 500 words on all the reasons why application outages and slowdowns are bad for business—they’ve been well documented throughout this blog and across the Web. Rather, my goal here is to underscore the idea that now, more than ever before, API performance represents a major piece of overall application performance—and as APIs continue to become increasingly integral to application development, so too must API monitoring. To bring it back to Game of Thrones, it’s time for developers and businesses reliant on APIs to have their Sansa moment of clarity—a Lannister may always pay his debts but an API won’t always meet its performance expectations.
Live API Monitoring Webinar: Join us on May 15 at 1:00 P.M. EST to listen as our expert panel explores how to ensure quality throughout every stage of the API lifecycle—from development to testing, production, and back with API monitoring.