We’ve all heard the stories about the overnight sensation that took decades to achieve. The “API Revolution” has that same feel to me. Some variation of APIs have been at the heart of application development for many years, but as the Web application world grew more and more connected and developers learned to leverage code built outside their own application, the API industry began to boom and flourish.
Most of us can now say that we have built our Web applications on a foundation of APIs, both internal and external. It’s a common conversation in planning meetings to talk about which APIs we need to expose to the outside world in order to drive business and, in some cases, to build APIs into the product roadmap.
With so much emphasis on the tiny API, it’s important to recognize its inherent power and make sure you build the appropriate safeguards to protect it.
API Failure can be One of the Most Impactful Failures
Because one API can affect so many applications/components, changing or deprecating that API can cause widespread failures that you may not be able to predict, particularly if that API has been made public. Once you’ve made your API available to other developers, either in a controlled fashion to trusted partners or in a public way to anyone with a developer/production key, you take on a responsibility to ensure that nothing affects the API’s performance. Factors like server load, the amount of data coming down (you always want paged results, for example), level of encryption, the quality of the controller code, etc, all affect the quality of the API and its performance.
Of course, you should test all of that before putting your API into production, but just like any other important feature, you should also monitor those factors after you deploy. It’s when your customers are banging on it in new and different ways that problems surface.
That’s where API monitoring comes in.
Industry Sees the Need
As we all become more reliant on our own and third-party APIs, the industry as a whole is beginning to see the importance of monitoring APIs in production. An API failure can be more catastrophic than an application-level failure because it can bring down so many other dependent applications. As time goes on, the API management platforms are all recognizing the need for some kind of analytics dashboard that goes beyond just showing usage statistics. Those are valuable as well but what about performance data for the APIs you rely on?
Companies like Apiphany and Mashape are starting to put dashboards together for their solutions, which solves a small piece of the problem. But they only provide generic data for the APIs they are specifically managing.
Only You Know What’s Most Important to You
That’s not a philosophical statement. That’s reality. You have adopted or built an API for a specific purpose within your application. You know what data matters to you, which transactions are most important to you, and therefore which monitors make the most sense for you. Building an API monitor is similar to building an API test but it requires an even more distilled viewpoint. An API test can be very complex and multi-stepped. An efficient monitor should run frequently, at least every hour, and check only the most important thing(s). You need to be able to identify that essential response that must perform well for your users and set a threshold for acceptable response time. Creating a monitor is an exercise in refinement – distilling your API tests to the single most critical action that signals continued success.
Your Users will Thank You
While you know how much of your application is driven by APIs, either yours or someone else’s, the consumers on the other end don’t know or care. They want an application that works quickly and cleanly when they need it. And they want you to take the responsibility for watching over all aspects of that application, including the APIs, to ensure that the application performance is what they expect.