Depending on how you want to categorize them, there are several different types of APIs, and they have various 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.
(Head to our “APIs 101” series to learn more about the basics.)
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. We’ll also add a bonus category, Composite APIs, which doesn’t quite fit neatly into any of these groups.
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 by style/protocol (SOAP, REST, Async, GraphQL, etc.). Let’s start with 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.
Public API examples and use cases
Science is one field where you’ll see a lot of free, open exchange of information, often via APIs. A good example is NASA’s open API portal, which allows developers to subscribe to its data, like its popular Astronomy Picture of the Day API. Another API makes NASA technology project data available in a machine-readable format.
Many of the contact tracing efforts during the Covid-19 pandemic are also good examples of apps that leveraged public APIs.
One country in the Asia Pacific uses APIs to enable fast, secure data-sharing. It is a good example of how one platform often supports a mix of public, private (or internal/external), and partner APIs:
“The new data-sharing platform supports multiple data-sharing scenarios, including teams inside and outside the government. By opening up data to citizens and civic organizations through a public-facing API portal, the organization is leading the way in engaging and involving citizens in decision-making processes. Each use case has its own governance and security framework based on the audience and the type of data being shared.
For example, an API that enables data-sharing between multiple government agencies will have significantly more stringent and complex governance and security requirements than an API used by only one team in a single government department.”
Which leads us to the next type of API…
How do internal APIs work?
Internal APIs, a.k.a. 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.
Virtually everyone is using internal APIs these days: many enterprises get started by building an API on top of an internal database. 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.
See also: API catalog + API marketplace: the yin and yang of your digital strategy
The distinction between internal/external, private/public can be cause for grief when it comes to security, which is why a zero trust approach – treating all APIs as if they might be exposed – is a stronger approach to API security.
Arun Dorairajan, Senior Solution Architect at Axway, notes that internal APIs tend to have a greater chance of being misconfigured inappropriately by internal teams. Threat defense cannot be limited to the enterprise’s perimeter: treat even internal APIs as if they were exposed externally, using rate limiting, throttling, and other methods to monitor their use.
See also: From Zombies to Legacy or Shadow APIs, it’s time to remediate your lost APIs
Beyond the security implications, this will also prepare your enterprise for external exposure of your APIs when the time comes to participate in a broader ecosystem.
Examples of internal/private APIs
Jeff Bezos set the standard at Amazon when he issued what is now known as the API mandate: that all capabilities would have to be designed and exposed as APIs.
Following this model, internal APIs allow different parts of an enterprise’s system to communicate and share data securely. Examples could include:
- User authentication APIs, to handle user logins and verify user identities within the company’s ecosystem. It ensures that only authorized personnel can access specific resources or perform certain actions.
- Data retrieval APIs, to collect data from various databases or internal systems upon request. Think of it like a librarian fetching specific books from the library shelves – it pulls the right data when needed, making it accessible for analysis or use in other applications.
- Workflow automation APIs for repetitive tasks or processes within the company’s workflow. For example, it could automatically generate reports, schedule tasks, or trigger actions based on certain conditions.
- Notification/alerting APIs: based on predefined triggers or events, these help keep everyone in the loop by delivering real-time updates on system status, user actions, or other important happenings.
Robert W. Baird & Co., a Wisconsin-based investment bank and financial services company, uses APIs’ ready access to their underlying data to deliver analytics insights to their customers.
“By improving the efficiency and effectiveness of our API development and management process, we’re cutting the time it takes from ideation to service deployment — helping us to bring value-added services to our customers faster than ever,” explains Jim Cornelius, Vice President, Solution Architect at Robert W. Baird & Co.
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.
Examples of partner APIs
Partner APIs include a wide range of services, from identity verification to payment processing or data syndication integration. For example, an e-commerce platform might provide an API for partners to embed product listings or checkout functionality directly into their websites or applications.
Healthcare partner APIs
Fast Healthcare Interoperability Resources (FHIR®) APIs are a good example of partner APIs: FHIR® is a modern standard for exchanging healthcare information electronically. Managing patient care is a delicate dance in a complex network of providers, payers, insurers, and more.
One U.S. health insurance company publishes FHIR® APIs via an open portal. Developers can use self-services to automatically register user accounts and healthcare apps — enabling the company to provide secure access to member data without increasing workload for its lean IT team.
“If an app requests all non-pharmacy-related claims for one of our members, gathering that data requires complex integrations with multiple external systems, each with their own OAuth implementations and client-side encryption keys,” explains a spokesperson.
Using an API platform, the insurer makes this integration logic transparent to its IT team, and leverages and access management capabilities for the new open API platform via the cloud.
Partner APIs in logistics and supply chain management
APL Logistics, a globally recognized leader in logistics and supply chain management headquartered in Singapore, uses APIs in its mission to help our customers move goods and services around the globe as seamlessly as possible.
In a recent keynote, Hakan Yaren, CIO at APL Logistics, described how this technology helps simplify complex partnerships.
“Our biggest success comes from our ability to shake hands with other providers,” explains Yaren. “In any given scenario, our customers will have hundreds of carriers, they’ll have suppliers, their factories, their customers… As a logistics provider, if we can connect the dots faster for them, that means revenue for both us and our customers.”
Connecting with partners via APIs in the open banking ecosystem
Finally, open banking APIs are another great example of third-party software providers and banks can build new, customer-centric financial applications and services.
With open banking partner APIs, banks can take advantage of the CX capabilities of new fintech startups. For example, they might leverage a fintech’s partner API to offer new services within their bank’s customer-facing apps.
Read more: how LUXHUB connects banks to the API economy.
In the following video, Commerzbank’s Katharina Haack explains how the German bank transformed its operations with APIs, achieving a milestone of 1 billion calls per month and unlocking new possibilities for business growth.
Why you might need a composite API
Finally, 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, and open/external 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.”
Different patterns and styles: API 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:
What is a 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.
Understanding SOAP APIs
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.
Looking back at RPC APIs
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.
What is a gRPC API?
gRPC APIs are based on Remote Procedure Call (RPC) technology, but with a twist – they use HTTP/2, a more advanced protocol that offers better performance and supports features like bidirectional streaming and multiplexing.
gRPC APIs can leverage Protocol Buffers (Protobuf) as a serialization protocol. This means that data is encoded in a compact and efficient binary format, making it faster to transmit and reducing bandwidth usage compared to traditional text-based formats like JSON or XML.
One key aspect of gRPC is its support for multiple programming languages, allowing developers to seamlessly create APIs and client-server communication regardless of the programming languages they use. This flexibility makes gRPC ideal for building distributed systems and microservices architectures.
In summary, gRPC APIs offer a modern, high-performance, and language-agnostic way for software components to communicate, making them well-suited for building scalable and efficient distributed systems.
Defining GraphQL APIs
GraphQL isn’t strictly an API protocol, but it does offer a powerful way for clients to interact with data stored in a server or database. Unlike traditional REST APIs where clients are limited to predefined endpoints, GraphQL allows clients to query and retrieve precisely the data they need, in a single request, using a flexible and intuitive syntax.
At its core, GraphQL is a query language that enables clients to describe the structure of the data they require, and the server responds with exactly that data. This approach provides clients with a complete understanding of the available data and allows them to fetch related data in a single request, reducing over-fetching and under-fetching issues commonly encountered with REST APIs.
One of the key strengths of GraphQL is its ability to layer over entire databases, allowing clients to access a wide range of data with specific queries. This makes it particularly well-suited for applications with complex data requirements, such as social networks, e-commerce platforms, or data-intensive dashboards.
Moreover, GraphQL’s human-like language makes it easier for even non-developers to write and understand queries.
Arun Dorairajan warns however that “with great power comes great responsibility”: GraphQL APIs should be built very carefully to ensure proper access control and prevent clients from accessing sensitive or unnecessary data.
Event-driven APIs, aka asynchronous APIs
In the last several years, event-driven or async 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.
In a recent demo of Axway’s Amplify Platform, Arun Dorairajan, Senior Solution Architect at Axway, shows why universal API management is so important in enabling your teams to work with all types of APIs, regardless of pattern, style, deployment or vendor gateway.
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.
Learn how to centralize all your APIs to optimize governance across teams, tools, and deployments and reduce security risks.