An Introduction to APIs for Product Managers

What is an API? That's a question that more and more folks are asking as APIs assume an increasingly important role in powering modern applications and infrastructure.

By now, virtually everyone who works in tech in some way has heard of APIs and might have a simple understanding of what an API is. But if your job doesn't involve working in a technical way with APIs or the applications that run on them, your understanding of how APIs really work, and what it takes to create and manage an API effectively, is likely to be limited.

If you're in that boat, this article is for you. It explains what an API is in a specific sense, but without getting too technical. The goal is to enable people who are not professional programmers to understand the ins and outs of APIs and API management. We'll delve into technical details when they matter, but avoid technical specificities when they aren't really important for non-developers.

What Is an API?

At a high level, an API (which stands for Application Programming Interface) is a set of rules and tools for governing how applications or services interact. APIs define how applications should (emphasis on should , because in practice applications don't always adhere to API definitions with complete accuracy) discover each other, exchange data, validate information, share resources, and so on.

If you prefer to think in terms of metaphors, you could define APIs in the following ways:

• If applications were cars, APIs would be traffic rules, in the sense that they define how cars are supposed to move around and interact on the road.
• If applications were food, APIs would be recipes. They govern how ingredients should come together in order to form complete meals.
• If applications were houses, APIs would be the blueprints that explain how various construction materials should be combined together to form a sturdy, secure house.

The point is: In the most basic sense, an API is a set of rules and tools for implementing them.

Who Creates APIs?

At this point, you might be wondering who gets to make up the rules that form the basis for an API.

The answer is that in most cases, the people who create APIs are developers who do so in order to allow other developers to interact with their applications.

If you're a tech company with a large platform, like Facebook or the AWS cloud, you'll probably want to create an API (or multiple APIs) so that other people can build applications that integrate with your platform in some way. But you don't need to be a major company to create an API — plenty of humble developers also create simple APIs to accompany applications or services that they build for one purpose or another.

While it is sometimes technically possible to integrate an application with a third-party platform without having an API available, doing so is often difficult and risky at best, because such methods are usually not officially supported. When a developer releases an API for his or her platform, he or she is providing an official, clearly defined set of rules that other people can follow in order to integrate with that platform.

In this way, APIs give developers the power to control not only what third parties can do with their applications, but also what they cannot do. In general, if a certain type of integration or interaction is not supported by an API, it won't be possible to perform.

Why Is Everyone Talking About APIs?

You may also be wondering why you hear people talking about APIs so often these days.

It's not because APIs are a new thing. The API concept has existed since the advent of distributed computing in the 1960s. APIs entered into widespread use as the Web matured around the year 2000. (For a historical overview of APIs, see this helpful article .)

Yet what has changed in the past several years is the widespread adoption of new application architectures (such as microservices), and deployment technologies (such as containers). In applications that are broken into a set of distinct microservices and deployed as individual container instances, APIs play a crucial role in allowing each component to communicate with the others.

In addition, the advent of massive cloud-based platforms and services has increased the importance of APIs. Public clouds like AWS and Azure, social media platforms like Facebook, and hosted business platforms like Salesforce would be much less useful if they didn't allow third-party developers to build applications that run on top of or integrate with these platforms. APIs make that integration possible.

Types of APIs

APIs can have several different types of architectures, some more popular than others:

• REST, the most popular architecture. REST is oriented around exposing data through APIs.
• SOAP, another popular architecture, which exposes information as services or resources rather than data loads.
• RPC, a type of API that lets one application call a function in another one. (RPC APIs are subdivided into XML-RPC and JSON-RPC, depending on which formatting they use; this difference is probably not something that will matter to you unless you are a developer.)

To be clear, the above are not specific APIs. They are examples of API architectures or styles that guide how particular APIs are formatted and implemented.

In most cases, you could use any of these API types to achieve a given goal. The API style used for a given API reflects developers' personal preferences and the architecture of the applications that it is designed to support. Generally speaking, if you are not a developer, the differences between REST, SOAP, and RPC are not likely to be important to you.

How Do You Manage and Monitor APIs?

To appreciate the full importance of APIs today, you have to understand not just what goes into designing and implementing an API, but also what it takes to manage an API and keep it working as intended.

Any organization that provides an API, or creates an application that uses someone else's API, needs to pay attention to several factors:

• The availability of the API. If the API stops functioning, so will applications that rely on the API, in most cases.
• The performance of the API. If the API responds slowly, application performance will degrade, too.
• The security of the API. Security vulnerabilities within APIs can provide entry points for intruders to break into an application or service. An API security vulnerability could be as simple as a way for someone to view sensitive data without having to authenticate.
• Application compliance with API requirements. You can create an API, but you can't compel applications to respect all of its rules. What if an application that uses your API sends data in the wrong format, or uses an outdated protocol? Undesirable results could occur, so you want to be able to monitor these issues.

APIs, then, are like any other type of important IT resource. They need to be monitored on an ongoing basis in order to keep things running smoothly.

Conclusion

If you've read this far, you hopefully have a better understanding of APIs than you did when you began. (If you don't, maybe you knew more about APIs to start with than you thought!) While the technical details of the ways APIs operate might matter only to developers, anyone who is involved in selling, supporting or managing applications and services that use APIs can benefit from a basic understanding of what APIs do, the formats they can follow, and the ways organizations can monitor and manage them.