How to explain what an API is – and why they matter

Some of us have used them for decades, some are seeing them for the first time on marketing slides


Systems Approach Explaining what an API is can be surprisingly difficult.

It's striking to remember that they have been around for about as long as we've had programming languages, and that while the "API economy" might be a relatively recent term, APIs have been enabling innovation for decades. But how to best describe them to someone for whom application programming interfaces mean little or nothing?

I like this short video from Martin Casado, embedded below, which starts with the analogy of building cars. In the very early days, car manufacturers were vertically integrated businesses, essentially starting from iron ore and coal to make steel all the way through to producing the parts and then the assembled vehicle. As the business matured and grew in size, car manufacturers were able to buy components built by others, and entire companies could be created around supplying just a single component, such as a spring.

This really gets to the heart of why APIs are important: they allow companies to access functionality supplied by others rather than having to build everything in-house.

Youtube Video

One of the most famous examples would be Stripe. By providing a complete suite of payment services consumable through an API, Stripe enables thousands of companies to build a business (eg, an e-commerce site) that handles payments without writing the code to process payments themselves. In this telling, APIs are the technology that lets companies focus on their specialty, whatever that may be, and programmatically access the functionality they need in support of the business (payments, shipping, notifications, etc.) as services provided by others (who specialize in those supporting areas). Importantly, APIs are designed to be consumed by other software, easing the integration of a software component into a larger system.

I would argue that one of the most important developments leading to the central role that APIs play in technology and business today was the realization that APIs could be exposed as endpoints on the World Wide Web. Early efforts in this space included XML-RPC (the basis for SOAP) and the RESTful approach first proposed in the PhD thesis of Roy Fielding. (Those of us who were around at the time remember the SOAP vs REST debates.) I consider this one of those inflection points that only looks inevitable with the benefit of hindsight.

We take it for granted now that anyone can expose their service via an API that is accessed using HTTP, and that the tools necessary to both build and consume those APIs are widely available.  

The world is now full of companies that are the software equivalent of the old automotive parts suppliers. Companies provide payment processing, shipping services, messaging, e-commerce platforms, all via APIs. For these companies, the API is the primary way that customers access their product. Sometimes it seems like the API is the product, since that is the part of the company that is the most visible – even appearing on billboards (at least in places like Silicon Valley).

Not only do APIs enable companies to focus on their primary business and leave supporting functions to others, it also enables them to offer services they might otherwise not be able to. For example, Stripe not only has expertise in detecting fraud, but they also have a breadth of historical data to feed into fraud detection algorithms that would never be available to a small or mid-sized company no matter their level of expertise. Companies can also offer additional services that go beyond their core business, eg: an airline can offer travel insurance simply by calling the API of a specialized provider.

One early and famous example of an API that enabled a whole host of innovations is the Google Maps API. All sorts of data visualization tools were built on top of it (such as local crime rates, disease outbreaks, etc), but beyond that, it enabled a generation of new applications, such as ride-sharing, that could not have existed without mapping and location services. So this was not just about enabling existing functionality to be handed off to a third party, it was also an enabler of new capabilities, much as the Socket API fostered the growth of networked applications that had not been imagined previously. 

I should emphasize that APIs are not just a way to access services from another company, but are an important tool for intra-company communication and collaboration as well. Jeff Bezos famously mandated the adoption of internal APIs at Amazon back in 2002, requiring that they be robust enough to support external users. While there is some debate as to whether that mandate has been truly embraced, the concept is sound and enables teams to develop their own functionality without destabilizing the work of others if they keep the API stable. It also laid the groundwork for AWS, which is essentially the result of making some of those internal APIs (and the services behind them) publicly available. 

As a networking person, I'm intrigued by how the increasing importance of APIs also changes the way infrastructure is built and managed

As a networking person, I'm intrigued by how the increasing importance of APIs also changes the way infrastructure is built and managed. The primary objects that we have to interconnect are no longer machines and routers but services that communicate via APIs. One salient example of this is the rise of service meshes: I think of a service mesh as the tool for managing policies, observability, access control, etc for communication over APIs.

Similarly, an API gateway (such as Kong) is an essential part of the infrastructure in this new world, providing services like authentication, load balancing, rate limiting and so on. Thomas Graf, founder of the Cilium project, summed it up nicely in the talk that first helped me understand service meshes: Layer 7 is the new Layer 4.  (Cilium and eBPF are also highly relevant in this new way of managing infrastructure.)

The proliferation of APIs means we need tools to manage their complexity. With many tens of thousands of APIs available, how do you even find the right one? This has led to "API marketplaces" – a sort of app store for APIs (see RapidAPI for example). And we shouldn't underestimate the challenges of integrating someone else's functionality into a complex system just because there is an API available.

Unlike the Lego bricks that often show up as an analogy when talking about APIs, there is a lack of standardization among APIs and connecting an API into a larger body of code takes more work than just "plugging it in." There is a rich body of work to help with this complexity such as "connectors" that try to make the process a bit more Lego-like. 

As someone who has been dealing with APIs for about 40 years, I was initially puzzled as to why there is so much more focus on them now than when I was starting out my career.

I think that the RESTful API development that started more than 20 years ago is one big reason, but I also like a point that I picked up from Martin's automotive analogy. The car industry had to get to a certain size before it made sense to have companies build just one component of the car rather than the whole thing. Similarly, the software industry is so much bigger now, especially once you accept that software is a core part of most businesses (or eating the world, as Marc Andreessen said).

So it stands to reason that, just as car companies no longer make their own steel, most companies will want to leverage APIs to bring in the best available functionality to enhance their products and services. ®

Larry Peterson and Bruce Davie are the authors of Computer Networks: A Systems Approach and the related Systems Approach series of books. All their content is open source and available on GitHub. You can find them on Twitter, their writings on Substack, and past The Register columns here.

Similar topics

Broader topics


Other stories you might like

  • Google battles bots, puts Workspace admins on alert
    No security alert fatigue here

    Google has added API security tools and Workspace (formerly G-Suite) admin alerts about potentially risky configuration changes such as super admin passwords resets.

    The API capabilities – aptly named "Advanced API Security" – are built on top of Apigee, the API management platform that the web giant bought for $625 million six years ago.

    As API data makes up an increasing amount of internet traffic – Cloudflare says more than 50 percent of all of the traffic it processes is API based, and it's growing twice as fast as traditional web traffic – API security becomes more important to enterprises. Malicious actors can use API calls to bypass network security measures and connect directly to backend systems or launch DDoS attacks.

    Continue reading
  • Zero Trust: What does it actually mean – and why would you want it?
    'Narrow and specific access rights after authentication' wasn't catchy enough

    Systems Approach Since publishing our article and video on APIs, I’ve talked with a few people on the API topic, and one aspect that keeps coming up is the importance of security for APIs.

    In particular, I hear the term “zero trust” increasingly being applied to APIs, which led to the idea for this post. At the same time, I’ve also noticed what might be called a zero trust backlash, as it becomes apparent that you can’t wave a zero trust wand and instantly solve all your security concerns.

    Zero trust has been on my radar for almost a decade, as it was part of the environment that enabled network virtualization to take off. We’ve told that story briefly in our SDN book – the rise of microsegmentation as a widespread use-case was arguably the critical step that took network virtualization from a niche technology to the mainstream.

    Continue reading
  • Remember the hype for NFV? Whatever happened with that?
    A technical deep-dive with a networking guru who was there

    Systems Approach Since our recent posts have been retracing the history, and recounting the lessons, of software-defined networking, it seems like a good time to do the same with the other sea-change in networking over the past decade: network functions virtualization, or NFV.

    Most people trace NFV back to the call-to-action [PDF] several network operators presented at the Layer123 SDN & OpenFlow World Congress in October 2012.

    My involvement happened over several months before that presentation, working with colleagues from BT, Intel, HP, Wind River, and TailF on a proof-of-concept that gave the idea enough credibility for those operators to put the NFV stake in the ground.

    Continue reading
  • The time we came up with a solution – and found a big customer problem
    A fascinating firsthand retelling of the technical history of MPLS

    Systems Approach One of the more satisfying conference experiences in my career was giving a presentation in the SIGCOMM 2003 Outrageous Opinions session, entitled: MPLS Considered Helpful.

    The Outrageous Opinion session was at that point about eight years old; I had chaired the first such session in 1995. The inaugural session contained a number of memorable talks, such as David Clark's actually-not-outrageous position that networking people should all become economists.

    By this stage in its evolution the session had turned into something of a stand-up comedy show, and the idea of making a hopefully humorous defense of MPLS in front of an audience that either ignored or disagreed with the admittedly controversial technology came to me while out on a run through the German countryside.

    Continue reading
  • You should read Section 8 of the Unix User's Manual
    And see the importance of open and accessible operations

    Systems Approach If, like me, you were a computer-science graduate student who cut your teeth on Berkeley Unix – complete with the first open-source implementation of TCP/IP – you know Section 8 as the cryptic System Maintenance Commands section of the Unix User's Manual.

    It was obvious, to me, that this concluding section warranted a closer look because the introduction warned: "Information in this section is not of great interest to most users." Judging by my taste in research problems over the years, reading Section 8 turned out to be a pretty good investment.

    But before getting to Section 8, you first learned about the rest of Unix, where you discovered how empowering it is to be able to build new internet applications. Anyone interested in how targeted investments in open-source software, coupled with affordable hardware, can spur innovation should study the role of the Berkeley Software Distribution (BSD) in the success of the internet.

    Continue reading
  • What is Magma? An open-source project for building mobile networks
    Amar and Bruce explain how cloud native principles can be applied to wireless connectivity

    Systems Approach This month's column was co-written by Amar Padmanabhan, a lead developer of Magma, the open-source project for creating carrier-grade networks; and Bruce Davie, a member of the project's technical advisory committee.

    Discussions about mobile and wireless networking seem to attract buzzwords, especially with the transition to 5G. And hence we see a flurry of “cloudification” of mobile networking equipment—think containers, microservices, and control and user plane separation.

    But making an architecture cloud native is more than just an application of buzzwords: it entails a number of principles related to scale, tolerance of failure, and operational models. And indeed it doesn’t really matter what you call the architecture; what matters is how well it works in production.

    Continue reading
  • SmartNICs, IPUs, DPUs de-hyped: Why and how cloud giants are offloading work from server CPUs
    Where this technology grew from, and what it offers you

    Systems Approach The recent announcements from Intel about Infrastructure Processing Units (IPUs) have prompted us to revisit the topic of how functionality is partitioned in a computing system.

    As we noted in an earlier piece, The Accidental SmartNIC, there is at least thirty years’ history of trying to decide how much one should offload from a general purpose CPU to a more specialized NIC, and an equally long tussle between more highly specialized offload engines versus more general-purpose ones.

    The IPU represents just the latest entry in a long series of general-purpose offload engines, and we’re now seeing quite a diverse set of options, not just from Intel but from others such as Nvidia and Pensando. These latter firms use the term DPU (data processing unit) but the consensus seems to be that these devices tackle the same class of problems.

    Continue reading
  • Everything you wanted to know about modern network congestion control but were perhaps too afraid to ask
    In which a little unfairness can be quite beneficial

    Systems Approach It’s hard not to be amazed by the amount of active research on congestion control over the past 30-plus years. From theory to practice, and with more than its fair share of flame wars, the question of how to manage congestion in the network is a technical challenge that resists an optimal solution while offering countless options for incremental improvement.

    This seems like a good time to take stock of where we are, and ask ourselves what might happen next.

    Congestion control is fundamentally an issue of resource allocation — trying to meet the competing demands that applications have for resources (in a network, these are primarily link bandwidth and router buffers), which ultimately reduces to deciding when to say no and to whom. The best framing of the problem I know traces back to a paper [PDF] by Frank Kelly in 1997, when he characterized congestion control as “a distributed algorithm to share network resources among competing sources, where the goal is to choose source rate so as to maximize aggregate source utility subject to capacity constraints.”

    Continue reading
  • Here's an idea: Verification for computer networks as well as chips and code
    What tools are available? What are the benefits? Let's find out

    Systems Approach In 1984, artificial intelligence was having a moment. There was enough optimism around it to inspire me to explore the role of AI in chip design for my undergraduate thesis, but there were also early signs that the optimism was unjustified.

    The term “AI winter” was coined the same year and came to pass a few years later. But it was my interest in AI that led me to Edinburgh University for my PhD, where my thesis advisor (who worked in the computer science department and took a dim view of the completely separate department of artificial intelligence) encouraged me to focus on the chip design side of my research rather than AI. That turned out to be good advice at least to the extent that I missed the bursting of the AI bubble of the 1980s.

    The outcome of all this was that I studied formal methods for hardware verification at a point in time where hardware description languages (HDLs) were just getting off the ground. These days, HDLs are a central part of chip design and formal verification of chip correctness has been used for about 20 years. I’m pretty sure my PhD had no impact on the industry – these changes were coming anyway.

    Continue reading
  • It's time to decentralize the internet, again: What was distributed is now centralized by Google, Facebook, etc
    The idea was to remove central points of failure, not introduce them

    Systems Approach Anyone who studies internet technology quickly learns about the importance of distributed algorithms to its design and operation. Routing protocols are an obvious example of such algorithms.

    I remember learning how link-state routing worked and appreciating the elegance of the approach: each router telling its neighbors about its local view of the network; flooding of these updates until each router has a complete picture of the network topology; and then every router running the same shortest-path algorithm to ensure (mostly) loop-free routing. I think it was this elegance, and the mental challenge of understanding how such algorithms work, that turned me into a “networking person” for the next thirty years.

    The idea of decentralization is baked quite firmly into the internet’s architecture. The definitive paper on the internet’s original design is David Clark’s “The Design Philosophy of the DARPA Internet Protocols” published [PDF] in 1988. Near the top of the list of design goals we find “Internet communication must continue despite loss of networks or gateways,” and “The Internet must permit distributed management of its resources.” The first goal leads directly to the idea that there must not be single points of failure, while the second says more about how network operations must be decentralized.

    Continue reading

Biting the hand that feeds IT © 1998–2022