There isn’t just one type of API (Application Programming Interface) but actually, there are four main types of APIs:
- Open APIs, aka Public APIs, are publicly available to developers and other users with minimal restriction. They may require registration, use of an API Key or OAuth, or maybe completely open. They focus on external users, to access data or services.
- 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 boundaries of the company. They are usually exposed to a public API developer portal that developers can access in self-service mode. While open APIs are completely open, there is an onboarding process with a specific validation workflow to get access to partner APIs.
- 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 different internal development teams for better productivity and reuse of services. A good governance process comprises 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.
- 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 categorize 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.
- Internal service APIs consist of exposing 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 specific device (desktop, mobile, tablet, VPA, IoT).
Types of API Protocols
To leverage these different types of APIs, we must follow certain protocols. A protocol provides defined rules for API calls. It specifies the accepted data types and commands. Let’s look at the major types of protocols for APIs:
REST (short for Representational State Transfer) is a web services API. REST APIs are a key part of modern web applications, including Netflix, Uber, Amazon, and many others. For an API to be RESTful, it must adhere to the following rules:
- Stateless—A REST API is stateless in nature, Client-Server Architecture
- 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.
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-premise scenarios, most developers now prefer developing in REST over SOAP.
An RPC is a remote procedural 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, so this makes 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.
APIs play a key 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 RPC, it allows for a loosely coupled layered architecture to maintain easily or update them.
Unlock Modern IT and Digital Success today.
Learn three practical tips for modernizing APIs.