APIs are like telephones: they have been around for quite a while, yet they have changed tremendously in recent years. And if you take the same approach to managing and securing them today as you did a decade or two ago, you are likely to end up with a lot of problems.
To prove the point, here’s a brief walk through the history of APIs, and a comparison of how they were used in the past with how they are used in the current age of cloud-native, microservices-based, containerized everything. As we’ll see, the tremendous changes in API use cases have necessitated major changes in API security and management.
A (Very) Short History of APIs
Depending on how you define them, the concept at the core of APIs – the idea of allowing software services to communicate with each other via a predefined interface – may go all the way back to the 1940s, although the term “application programming interface” didn’t emerge until the late 1960s.
That said, the type of API that most modern programmers would recognize as such dates to the heady days of the dot-com era (which, for those of you too young to remember, means the late 1990s and early 2000s). That’s when companies like Salesforce and eBay began publishing APIs that allowed third-party developers to write applications that interacted with the companies’ own platforms.
These APIs opened up a whole new world of possibilities for building an interconnected, interactive Web, but their use cases were pretty narrow from a technical perspective. For most of the 2000s, the main purpose of APIs was to allow different applications or services on the Web to talk to each other. Developers created travel booking websites that pulled flight data from airlines’ APIs or booked rooms through hotels’ APIs, for example. Or, they leveraged APIs to build apps that connected to social media networks, making it possible to create user experiences that didn’t exist natively on the social media platforms.
To the extent that APIs were used for internal management purposes at this time, use cases were mostly limited to doing things like pulling monitoring and security-related data from third-party sites. You might have used your Web host’s APIs to help monitor the health of your infrastructure, for instance.
What you didn’t do (in most cases, at least) was rely on APIs as the glue that held your entire software stack together. If an API failed, or the data it exposed was not properly secured, the heart of your IT estate was not at risk. Integrations with third-party services might break, but that was about it.
Modern API Use Cases
Fast forward to the present, and APIs have assumed much more importance for applications. Rather than serving merely to import third-party data into an application, APIs have become an essential component of the architecture that makes the application work.
Most microservices rely on internal APIs to discover and communicate with each other. And if your microservices can’t talk to each other, your microservices-based application stops working.
Likewise, you can’t effectively deploy a containerized application on an orchestration platform like Kubernetetes without using APIs to manage the various moving parts of your cluster – worker nodes, master nodes, pods, sidecars, and so on.
And it’s pretty hard to deploy applications scalably in the cloud without using APIs to help automate application management, balance traffic, and so on. Although it’s possible to manage cloud environments in other ways – via a Web interface or CLI – an API-centric approach is usually the most efficient.
The conventional, dot-com era use cases for APIs remain important today as well. Developers still frequently rely on APIs to integrate applications with external platforms, and to monitor and secure third-party resources. But the role of APIs in modern, cloud-native environments extends far beyond mere integrations and monitoring.
Modern API Security and Management
All of the above raises the stakes of properly securing and managing your APIs.
Again, it’s one thing if an API issue stops your app from integrating with a third-party service. The core of your app will still work; you’ll just temporarily lose functionality like the ability to pull contact lists from users’ social media accounts, for instance.
It’s another thing when the APIs that allow your microservices to function properly stop working – or, worse, the APIs lack proper access controls and expose sensitive internal application data to untrusted endpoints. In situations like these, your application may stop functioning entirely, and/or you risk a major security breach.
This is why investing in proper API design, management, and security is essential for modern developers. Teams need to know what their APIs can and can’t do. They need to manage access control at a granular level to ensure that APIs provide each software service with the resources it requires, but no more. They must collect and analyze data about API behavior to detect anomalies that could signal a breach or insecure configurations.
Conclusion: Security for an API-First World
We live in an API-first world, in which APIs are at the very core of modern software stacks. In order to ensure that dependency on APIs doesn’t become a liability, developers must learn to place as much emphasis on properly securing and managing APIs as they do on taking advantage of APIs as a way to build scalable, loosely coupled applications.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure, and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.
