API Basics

4 types of APIs and what makes each one unique

Depending on how you want to categorize them, there are several different types of APIs, and they have different scopes, benefits, and intended audiences, which makes each of them uniquely suited for different purposes.

API stands for Application Programming Interface. APIs contain a collection of actions (or requests and responses) that developers can access. The API also explains what it accomplishes, like “Save as” for example. Finally, the API contains the information developers need to structure those requests and responses.

It sounds complicated, but breaking all of it down can help. So, what are the different types of APIs available? Let’s take a look at how they differ.

Four types of APIs by audience

APIs come in different shapes and sizes, giving developers the flexibility to choose the type of APIs that best suits their purposes. A popular distinction is to categorize them by their intended audience, which gives us the following three categories: Open APIs, Partner APIs, and Internal APIs. I’ll also add a bonus category, Composite APIs, which doesn’t quite fit neatly into any of these categories.

Of course, there isn’t just one way to categorize APIs: you could sort them by business use, or by vertical or technical type, or also by protocol (SOAP, REST, Async, GraphQL, etc.). Right now, let’s talk about types of APIs by audience.

Public APIs

Public APIs, also called external or open APIs, are publicly available to developers and other users with minimal restriction. They may require registration, an API Key, or OAuth. Some may even be completely open – in fact, while the terms public and open are often used interchangeably, not all public APIs are open. (And to make matters even more confusing, Open API and OpenAPI are two different things!) When we look at them in terms of intended audience, public APIs focus on external users to access data or services.

What are partner APIs?

Partner APIs are APIs exposed by/to the strategic business partners. They are not available publicly and need specific entitlement to access them. Like open APIs, partner APIs are the tip of the iceberg because they are the most visible ones and are used to communicate beyond the company’s boundaries.

They are usually exposed to a public API developer portal that developers can access in self-service mode. While open/public APIs are completely open, there is an onboarding process with a specific validation workflow to access partner APIs.

How do internal APIs work?

Internal APIs, aka private APIs, are hidden from external users and only exposed by internal systems. Internal APIs are not meant for consumption outside of the company but rather for use across internal development teams for better productivity and reuse of services.

A good governance process involves exposing them to an internal API developer portal that connects to the internal IAM systems to authenticate and allow users to access the right set of APIs. And as François Lascelles points out, the distinction between internal/external, private/public can be cause for grief when it comes to security, which is why zero trust – treating all APIs as if they might be exposed – is a stronger approach to API security.

types of APIs

Why you might need a composite API

Composite APIs combine multiple data or service APIs. They are built using the API orchestration capabilities of an API creation tool. They allow developers to access several endpoints in one call. Composite APIs are useful, for example, in a microservices architecture pattern where you need information from several services to perform a single task.

Data and service APIs

Beyond the difference between internal, partner, open, and composite APIs, we should mention another approach to categorizing APIs:

  • Data APIs provide CRUD access to underlying data sets for various databases or SaaS cloud providers. These APIs are needed to serve some fundamental data coming from SaaS applications, with help from SaaS connectors or internal data stores. Legacy portals, for example, where the login and password are saved in the web.config file, are one of the most common examples.
  • Internal service APIs expose internal services, reflecting parts of internal processes or some complex actions.
  • External service APIs are third-party services that can be embedded in the company’s existing services to bring additional value.
  • User experience APIs leverage composite APIs to help app developers provide the right experience for each device type (desktop, mobile, tablet, VPA, IoT).

See also: How APIs are transforming businesses and why you can’t afford to ignore them

As you can see, there are many options available, and we’ll certainly see more to come. Just look at the explosion of artificial intelligence APIs in 2023: Treblle’s Anatomy of an API report recently found that AI APIs saw a remarkable 96% growth compared to 2022, and it’s unlikely to slow down soon.

Axway Catalyst Emmanuel Methivier predicts that the battle for generative and conversational AI will be won on the API front.

“2024 will probably see the emergence of a new approach to interaction between information systems, thanks to the arrival of a new consumer: the AI-powered assistant. The progress and democratization of generative AI tools will create new uses.”

Discover more insights on digital trends for 2024 by Axway business, industry, and technology thought leaders.

Types of API protocols

To leverage these different types of APIs, we must follow specific protocols. A protocol provides defined rules for API calls. It specifies the accepted data types and commands. Let’s look at the significant protocol types for APIs:

1. REST API

REST (short for Representational State Transfer) is a web services API. REST APIs are crucial for modern web applications, including Netflix, Uber, Amazon, etc. For an API to be RESTful, it must adhere to the following rules:

  • Stateless—A REST API is, by nature, a stateless Client-Server Architecture
  • Uniform Interface—A client and server should communicate with one another via HTTP (HyperText Transfer Protocol) using URIs (Unique Resource Identifiers), CRUD (Create, Read, Update, Delete), and JSON (JavaScript Object Notation) conventions.
  • Client-Server—The client and server should be independent of each other. The changes you make on the server shouldn’t affect the client and vice versa.
  • Cache—The client should cache the responses as this improves the user experience by making them faster and more efficient.
  • Layered—The API should support a layered architecture, with each layer contributing to a clear hierarchy. Each layer should be loosely coupled and allow for encapsulation.

APIs play a vital role in the development of any application. And REST has become the preferred standard for building applications that communicate over the network.

REST fully leverages all the standards that power the World Wide Web and is simpler than traditional SOAP-based web services. Unlike other APIs, it allows for a loosely coupled layered architecture to easily maintain or update them.

2. SOAP API

SOAP (simple object access protocol) is a well-established protocol, similar to REST in that it’s a type of Web API.

SOAP has been leveraged since the late 1990s. SOAP was the first to standardize the way applications should use network connections to manage services.

But SOAP came with strict rules, rigid standards were too heavy, and, in some situations, very resource-intensive. Except for existing on-premises scenarios, most developers now prefer developing in REST over SOAP.

3. RPC API

An RPC is a Remote Procedure Call protocol. They are the oldest and simplest types of APIs. The goal of an RPC was for the client to execute code on a server. XML-RPC used XML to encode its calls, while JSON-RPC used JSON for the encoding.

Both are simple protocols. Though similar to REST, there are a few key differences. RPC APIs are very tightly coupled, making it difficult to maintain or update them.

To make any changes, a new developer would have to go through various RPCs’ documentation to understand how one change could affect the other.

4. Event-driven APIs, aka asynchronous APIs

In the last several years, event-driven APIs have gained steam because they offer an excellent solution for some specific pain points and use cases in our always-on, data-heavy world.

Event-driven APIs differ from REST APIs because of the way they transmit information in quasi real-time. They are particularly helpful in cases like stock market trackers, which require constantly updated data, or IoT devices which monitor real-time events. For this type of data, using a REST architecture would require constant and onerous back-and-forth requests to a server – much like a child asking “are we there yet?” in the backseat of the car on a road trip.

An event-driven architecture (EDA) allows the source to send a response only when the information is new or has changed. There are a few ways to achieve this result, and some popular event-driven API interaction patterns are Webhook, Websocket, and streaming.

APIs are digital building blocks for your business

Regardless of what types of APIs you use, they are game changers because they serve as building blocks for modern digital solutions.

Packaging up discrete digital capabilities as APIs makes it possible to recombine things more quickly, giving companies the flexibility to build new products and services out of existing APIs, contribute new capabilities as building blocks to the platform, and improve solution space by making all capabilities available for reuse.

See also: How to unify all your API assets so they’re easier to consume

There’s no way around it: APIs are critical to your business. They’ll allow you to integrate new applications with your existing software. They allow you to innovate without changing or rewriting code. They act as a gateway between systems which will enable you to expand the digital experiences you offer your clients at any given time.

And crucially, with the right business vision for your APIs, they can drive extraordinary results.

Whatever the type of API, they often end up scattered throughout the enterprise. See why businesses need a full view before it’s too late by adopting universal API management.