“API” has become a popular term in the tech space, and for a good reason – APIs enable an incredible range of functionality, extensibility, and scalability to many organizations in a diverse range of industries. That said, defining what an API actually is in an academic sense can be a little difficult, as there are a few interpretations. The industry talks a lot about APIs but seldom talks about the different kinds of APIs.

This piece will do precisely this, discussing two core forms of APIs: the Web API and the System API. These two API types are unique, and as new technology has blurred the lines between them, identifying what each type of API actually is has become more difficult. Nevertheless, understanding the core concepts behind these types of APIs is quite essential.

What is an API?

An API, or Application Programming Interface, is best understood in simple terms as an interface that states and facilitates how different systems or users of those systems can interact with one another. This stated form and function of communication is necessary due to the nature of programs and applications in general.

Programs and applications typically function in regards to themselves and the system that they live in. They are essentially selfish — smart about themselves, but they become less intelligent once they operate elsewhere. A media playing application only really needs to know how to play music — why should it care if you can stream the titles of your current playlist to social media?

However, with increased user demand towards inter-functionality, the facilitation of communication between applications and other systems has become incredibly important. It’s not just enough for a thermostat system to run an air conditioning unit — users would also like to check the status of that thermostat remotely, set schedules, and more. There are a couple of ways to do this, but they functionally reduce to two core approaches — built-in or through interconnection.

Yes, one could ask every application or program to understand how to work with all other potential programs through a built-in set of instructions, but at that point, you’re essentially replicating a translation matrix to every single program over and over again. This built-in approach has been used in the past on consumer-facing applications and programs, which is why early software systems were essentially tied to a specific set of hardware and implementations. As a result, the software was coupled and less reusable. It was an incredibly heavy way of dealing with things and didn’t promote interconnectedness as much as it promoted interdependence.

There is another approach. Since most programs need the same basic methods to communicate and work together, we can take that layer of connection between the programs and form an entirely separate interface. This interface allows programs and applications to be somewhat selfish with their attention, merely knowing the method by which they communicate with that interface. In other words, it reduces the complexity of communication.

That is the core concept behind the API — a translation layer that reforms requests and instructions to pass it along to other accepting partners.

A Linguistic Explanation

Another way to think about APIs is to consider a business with multilingual components. Imagine an accountant speaks French, the designer speaks Japanese, and the manager speaks German. How does the organization work together?

In theory, you could ask each of them to learn the other workers’ languages, but this creates a scenario where every worker would need to know at least three languages (and potentially more if you want to work with an external business).

Better, then, that you hire a translator — someone who can translate each interaction within a set specific system of criteria which enables everyone to work together. This translation layer eases the workflow and empowers the workers to do their work in the way they wish to while not worrying about how it will be intercepted, understood, transformed, and passed on by others.

This is an API.

What is a Web API?

From this backdrop, let’s define what a Web API is. Web APIs are often referred to more generally as “web services,” and in essence, they are precisely that — a service that lives on the web and facilitates interactions. They are the APIs that allow a user, system, or service to interact with an endpoint that then interfaces with a larger internal system. These interactions are governed by a set of rules and instructions, allowing a request to come from a user on an entirely different system in a form and function that is known and serviceable.

As an example, when a user utilizes a web radio service, their system is contacting the endpoint of a specific API, which then serves the content as requested and in the form requested. When the web radio service reaches out to another service to grab something like audio credits or hyperlink elements, it doesn’t use its own rules and known set of interactions to do this. Instead, it works with yet another API through its declared endpoints to serve this content.

This is the concept of a Web API — all interactions are coordinated through this web system to facilitate more dynamic and successful interactions. When Web APIs are discussed, we’re typically speaking specifically about serving content over HTTP via various methodologies and paradigms. REST, GraphQL, and gRPC are commonly used approaches for HTTP-based APIs.

While web API design styles warrant many other articles, the modern landscape has become roughly separated into two general categories, regardless of paradigm or mechanism — standalone APIs and APIs as a part of an offering. This goes by many names, but you will often see a dichotomy between single-use APIs that exist to serve a particular function and APIs that are part of a product or service (aka APIs in the form of Platform-as-a-Service, APIs-as-a-Product, etc.)

What is a System API?

A System API is more akin to a traditional API format, where an API takes some input as a guideline to handle a particular system’s internal functions. In this classic form, a System API may take instructions from a user application on the same local system or a hardware instruction input, like a keypad or touch screen. In essence, the API is a layer between hardware instruction and software instruction and is typically built explicitly for a narrow application.

Of note with System APIs is where they typically “live.” These APIs are often served either from a library, SDK, or some other “local” service. Note that when we reference “local” here, we mean “local” in terms of the system’s location to the web — web APIs predictably serve content over the web. In contrast, System APIs typically serve data by being integrated into a project as part of a library used to run an application. A rough metaphor would be that a Web API is a takeout, and a System API is a home-cooked meal.

Interestingly, the line between System API and Web API has become quite blurred in recent years. Many Web APIs have taken the place of the core System APIs, or at least, have integrated so closely that the difference has become academic at best. While we will dive into this in a moment, it bears consideration when discussing these interactions, as the line has blurred significantly, making lines of delineation somewhat tricky.

Interactions Between Web APIs and System APIs

Sometimes Web APIs and System APIs interact with one another. Let’s consider the flow of a user request into a collection of APIs. First, the user client makes a request through the Web API. This API has a delineated set of interactions. If the user client request is within these interactions, the request is then taken from the external endpoint into the system itself.

This API is, in this flow, essentially an intelligent traffic router — it knows where to send the request, and in most cases where a Web API and System API touch, it is at this stage that the traffic crosses over.

Once inside the system itself, the System API transforms the request and enacts the request resolution. These are the basic paradigms of Web and System APIs — a Web API utilizes a schema by which web clients and systems can understand interactions with other web clients and systems. In contrast, a System API converts this to an interaction that can be understood by the system itself. These two distinct domains — Web APIs as interconnected and diverse, System APIs as limited in connectivity and specific in purpose and action — have been blurred as more devices have taken on an interconnected focus.

Let’s look at one such case.

Internet of Things (IoT) Devices

Perhaps the most obvious example of these blurred lines is the growing Internet of Things (IoT). The IoT is based upon a simple concept — many small devices connected together to accomplish various tasks, often leveraging processing, storage, and other “system-like” functions off-device. Each device typically does something very specific — for instance, reporting temperature, exporting logs, etc. It networks with other devices to form a type of “meshed network of devices.”

The blurring of Web API and System API comes from the fact that these IoT devices are, by definition, connected through Web APIs. Everything is handled via endpoints on a networked series of connections. These APIs take form-limited and structured requests from various users, outputting a variety of content and responses. But these outputs are generated by the exact same functions that would typically be called the System API. In this case, the System API and the Web API are one and the same. To be more specific, a collection of IoT devices can function as a group of peered resources in the form of a sort of intranet, where all the devices exclusively connect to each other and the local network, with only the edge device actually connecting with the web. This is where that blurring occurs — the IoT devices are technically functioning as a sort of exploded local machine, with each function existing in its own device and calling its own libraries and functions.

While this is a very particular case, it has actually become more common as the years have progressed in other domains as well. Internet-connected System APIs are only very narrowly divided from Web APIs that also connect to the systems they touch, almost to the point where the difference has become academic. Internet-connected watches, instruments that utilize Bluetooth to connect to smart devices for tuning, and other devices all blur the line so substantially that they can almost be said to operate as a third type of API altogether — some in the API space have even taken to calling these Device APIs.

Conclusion

Ultimately, even if the difference between System APIs and Web APIs is becoming blurred, it still helps to understand the core differences academically. Suppose an API touches both system and the web. In that case, it’s best to think of the implementation as two sides of the same coin — this can have marked impacts on the overall performance, security, and general flow of the end API and the system upon which it rests. Understanding the network at large and the inter-functional parts and systems that live on it is extremely important.

Did we clarify the differences? Do you believe that the difference is still substantial enough to warrant conversation? Do you have a different interpretation? We’d love to hear from you. Please let us know in the comment section below!