6 Different Types of APIs | When to Design Which

API Strategy

6 Different Types of APIs | When to Design Which

·  4 Min Read

Learn about the 6 main types of APIs and when to use them in your enterprise.

After reading this blog, you’ll know the 6 main types of APIs and their use cases as part of a robust API program.

Application programming interfaces (APIs) are a flexible way to provide connectivity between systems and their data in your enterprise architecture and ecosystem. We can use them to expose functionality and data in an easy-to-consume way by API consumers and applications. That’s why they’re a key part of modern digital business.

But, there are different types of APIs for different “jobs”. A quick example: if you’re a server a restaurant, you don’t want to come and keep asking the chef if your tables’ food is ready. You listen out for the bell ring from the kitchen that signals “grub’s up!”. That’s the equivalent of picking an event-based API over a REST API.

We’ve put together definitions and examples of the key types of APIs, as well as the common API protocols/styles. It’s important to know which different type of API you need to ask your API designers and developers to create, so that it’s fit for your use case.

Types of APIs and their use cases

Icons of the different types of APIs

We see enterprises using the following 6 API types:

Business Capability APIs

These are your core digital business building blocks. Business capability APIs are essentially the automation of your business functions. Internally or externally visible units of value meaningful to their environment and consumers. They’re further defined by business behavior such as business functions and business processes, implemented for execution by process engines, applications and application services.

Business capability API common subtypes: Internal Private and External Public (e.g. Open APIs/Public APIs)

Example: An Account Management API for a large bank with functions that search for, create, update, and delete customer account details.

System (IT) APIs

System APIs (also known as IT APIs) are those that are mapped to, and integrated with, existing applications. These expose data from back-end systems within your organization within a controlled yet seamless fashion.

System (IT) API common subtypes: Public, Partner Common, Internal Common.

Example: A KYC (know your customer) API which includes face verification, address verification, document verification, 2-factor authentication, and consent verification services.

Partner API (also known as 3rd Party APIs)

Partner APIs (sometimes called 3rd party APIs) enable you to bring in external functionality or data from within your API ecosystem. Of course, it’s not always best to spend time and effort building in-house! That’s why this type of API is great for accelerating time to market and ensuring frictionless consumer experiences for your products and services. They’re often accessed using an onboarding and approval process.

3rd Party API common subtypes: Partner, Public, Partner Private

Example: Subscribing to and integrating the Twilio messaging API to notify customers of product offers available to them.

Point to Point APIs

Point to Point APIs are used to directly integrate endpoints from two or more systems, with a single transform of data in the process. They form a tight coupling and are most commonly associated with legacy services.

Example: An API which takes data from an ERP system and updates an HR database.

Façade/Experience APIs

Sometimes, back-end systems may be too complicated and “messy” to expose directly. This is where Façade/Experience APIs come in. They expose a streamlined “façade” of the internal system that is much easier for consuming developers to use.

Example: An Audience API that aggregates consumer spending from specific segments of a back-end system of record.

Product Bundles ( including API products and composite APIs)

Product Bundles are groups of reusable APIs. A Product Bundle is an encompassing concept and term for enterprises. You may be familiar with the concept of API products and composite APIs, and indeed both can be a Product Bundle.

Enabling bundling of multiple types of service is the next evolution of the API product mindset. For example, a product bundle could contain a REST API, Events-based API, and SOAP service (see later for definitions on these).

The ability to facilitate the continually and innovatively recombination of APIs is a key differentiator for enterprises.

Example: A money transfer bundle containing the account management and KYC APIs from earlier examples (amongst several more).

Different API Protocols and Architectural Styles

In addition to the 6 core types of APIs, there are the following main different architectural styles and/or protocols:

  • REST: Representational State Transfer is a set of architectural principles for designing APIs. 6 core principles, lightweight interfaces, and uses resource methods to transmit data from a provider to a consumer by an API call from the consumer. RESTful APIs have become a preferred style for creating new APIs due to their lightweight and flexible nature.
  • SOAP: Simple Object Access Protocol is a “a definition of how web services talk to each other or talk to client applications that invoke them”. SOAP services have stricter rules than REST style, and are driven by function instead of data. Most enterprises will have their legacy services primarily written as SOAP services.
  • Event-driven/streaming: Event-driven APIs (also known as event-based APIs, async APIs, message streams, events amongst others) don’t rely on a consumer calling a provider for data. Instead, an event triggers a response/message, and clients subscribe to the event notification. Event-driven styles are a growing trend and many large enterprises are currently building out event-driven architectures alongside their existing maturing API-centric architecture.

A tip for managing multiple types of APIs at scale – manage in a holistic catalog with configurable design types

As you mature the API program at your enterprise, you’re likely scaling the numbers of each of these API types. It’s importantly to catalog and manage these APIs holistically, and surround them with rich metadata, to ensure:

  • A single source of truth for all APIs
  • Easy discovery of existing APIs by both business and IT users
  • API reuse
  • Reducing duplication and helping minimize technical debt
  • Standardization of APIs

However, whilst reading this blog you may be thinking “but my enterprise calls these API types something different!”. That’s almost always the case.

That’s why we suggest looking for an API cataloging tool that has configurable API types like the ignite platform – so you can use your organization’s language. This further helps drive discovery and reuse. And done right, these APIs, Services, and Events encapsulate and modularize your business and technical functions. This is critical to transforming to a composable enterprise.

About the Author

Learn the Best API Practices and Get the Latest ignite Updates

What can we help you find?

Use of cookies

We use cookies to make the website optimal and to continuously improve it. By continuing to use the site, you consent to the use of cookies. Please refer to the privacy policy for more information.