Growth of APIs for new services
This is the second of a series of articles that introduces and explains API security threats, challenges, and solutions for participants in software development, operations, and protection.
Growth of APIs
When Salesforce and eBay became the first major Internet players to focus on making their systems available to external programs via an API (versus traditional means such as command line interface), they ushered in a new era of so-called open computing.
What this meant was that rather than close off their software to the external world, as was the general practice before 2000, open computing encouraged systems to allow for others to have their software connect directly. As one might guess, the result was explosive growth on the Internet.
Imagine, for example, how difficult it might have been for Amazon (which published their first API just after Salesforce and eBay), to have grown so quickly if they had walled off their applications from other systems on the Internet. Without open computing, they would have had trouble integrating security protections, purchasing partners, supply chain management, authentication services, and on and on. All the things we have come to expect from a modern Internet service now depend on open computing and APIs.
More recently, API usage has seen even greater exponential growth driven by several factors – the first of which is the ubiquitous mobile device. By making the Internet accessible anywhere, anytime, and to everyone – mobility increased the demand for more connected and integrated services. It’s hard to imagine API-heavy services such as Salesforce, eBay, and Amazon experiencing such great success without the explosion of mobile device usage.
Additional factors driving API usage might be less familiar to normal users. Software designers have moved, for example, to modular applications, which makes it easier for them to add features more quickly and to iterate more rapidly during software development to create standard interfaces. Network architects have also begun to adopt an approach known as a service mesh, which depends on hyper-connectivity between software workloads. As one might expect, this connectivity is achieved through the use of APIs.
Invention of the REST API
In 2000, Roy Fielding completed his PhD at the University of California at Irvine. His PhD thesis, unlike most such works, includes arguably the first meaningful description of what we would now refer to as an API. Specifically, “Architectural Styles and the Design of Network-Based Software Architectures” ushered in a new era of programming style for the web, using a technique referred to as Representational State Transfer or REST.
The specific details of REST APIs are beyond the scope of this short summary, but we can outline some of the more salient constraints that help define this uniform set of software connector interfaces. The first design constraint in the REST style of programming involves stateless processing for all client-server interactions. By reducing API requests to a single transaction (versus including history), it become much easier to create proper “visibility, reliability, and scalability,” as Fielding explains in his thesis.
Additionally, cache constraints are added to the REST API model to reduce the latency of interactions. The most central design constraint of REST APIs, however, is the uniformity of the interfaces that is inherent in the overall design. This is complemented by design layering, which reduces the complexity at a given layer (via abstraction of lower layers) and code-on-demand, which “allows client functionality to be extended by downloading and executing code in the form of applets or scripts,” again, as Fielding describes in his work.
The implications of REST API design from Fielding’s PhD proposal were immediately felt across the entire web community. Soon after publication of the thesis, companies like Salesforce and eBay began to demonstrate how the programming style as associated uniform connector model could substantially increase their reach to the web. They quickly saw that APIs not only made their interfaces more standard, but made the services they provided to the external community much more accessible and more popular.
Contributing author: Matthew Keil, Director of Product Marketing, Cequence.