API Design Patterns
APIs bring significant benefits when used in different scenarios.
In this article, the most relevant kinds of scenarios are identified and described. These kinds of scenarios are called "Patterns". For each pattern, the following attributes are covered:
Pattern #1 Application Fa?ade
Description
Application Fa?ade is a design pattern that provides a simplified interface to an application.
Problem
Consumers need access to application services. The application is complex and internal complexity is not relevant for the consumers of its services.
Solution
An Application Fa?ade is an API that identifies, specifies and implements a simplified interface to the application, hiding the internal details of the application to the consumers.
Structure
Pros and cons
? Application Fa?ade is easier to understand than the whole application.
? Application Fa?ade is more stable -- Internal changes in the application don’t impact the API. Therefore, consumers are not required to change every time there is an improvement or a fix in the application.
Examples
For example, the services of the ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management) applications of a company can usually be consumed using APIs.?
Here are some example APIs that can be though as Application Fa?ades:
Pattern #2 Proxy API?
Description
Proxy API is a design pattern that allows application teams to provide a substitute for the actual service, allowing them to perform something either before or after the request gets through to the actual service.
Problem
When dealing with services, there is a set of actions that application teams will end up wanting to perform either before or after the execution of a service in the backend.?
These actions are more or less standard, and include, for instance, performing security checks, generating logs, masking personally identifiable information (PII), throttling, controlling quotas based on SLAs, etc.?
Spreading these actions across the whole application is not cost effective, as it is complex, error prone, and hard to maintain.
Solution
A Proxy API allows application teams to define and enforce in a single place the execution of the actions needed. These actions are often referred to as policies.
Structure
Pros and cons
? Proxy APIs reduce application complexity.
? Policies can be applied at a centralized place without requiring changes spread all over the application.
Examples
Most modern API Managers support the creation Proxy APIs and enforce policies on them.?
Pattern #3 Adapter API
Description
Adapter API is a design pattern that allows a service with an interface to be consumed using another interface specification (or contract).
Problem
An application provides a service which implements an interface specification. However, the consumer expects the service to implement another interface specification.
领英推荐
Solution
An Adapter API allows to map the requests and responses to and from the application to the expected interface specification without making changes to the service in the application.
Structure
Pros and cons
? Using the adapter API allows the reuse of existing services by adapting the format of the request and response messages.
? It can be applied without making changes to the application .
Examples
Imagine there are payment services already implemented in an organization and now it has to comply with PSD2 requirements. Instead of creating PSD2 services from scratch, the organization might be able to adapt their existing services to the standar PSD2 API.?
Pattern #4 Orchestrator service
Description
Orchestrator service is a design pattern that allows the creation of new services by composing responses from other services consumed through their APIs.
Problem
How to quickly create a new service based on existing services.
Solution
Create a new component (Orchestrator service), responsible for interacting with existing services through their APIs in order to provide new value-added services.
These value-added services can provide extended, aggregated, or post-processed information, and more complex features involving several backend services.
Structure
Pros and cons
? New services can be created by reusing existing ones.
? Innovation is easier than ever. Services created by the organization and services provided by specialized third party organizations can be seamlessly integrated to create new and better services.
Examples
Imagine what organizations could do if it was possible to easily integrate the information they have with the news, stock exchange information, satellite imagery, social media trends, weather forecast, machine learning, artificial intelligence services such as artificial vision, natural language processing, etc. to make automated decisions and offer new and better services to theur customers. This can be done today, applying the Orchestrator service pattern.?
Pattern #5 Layered API Architecture
Description
Layered APIs is a design pattern that allows service logic to be decomposed in layers, fostering reuse.
Problem
Consumers require customized interaction sequences and data formats. Backends implement different interfaces and have specific integration requirements. Creating a service for each combination of customer requirements, business logic and backend integration might be a cartesian product where complexity quickly (exponentially) grows.
Solution
Follow a layered architecture design, also known as n-tier architecture. APIs are organized into layers, each one performing a specific role.?
There is not a fixed number of layers to be implemented. However, most layered architectures consist of three standard layers: presentation, business, and persistence.?
In some cases, some layers can be omitted or combined.
Structure
Pros and cons
? Layered APIs foster reuse, reducing development effort and time.
? Cohesion is increased.
? Quality is often increased, as new developments are created on the foundation of APIs that have been tested in real life scenarios.
Examples
Imagine an organization already has a website and a mobile application for its customers to browse and purchase products. Now, senior management decides to enable customers and parties to query the information and acquire the services the company provides via an API. Chances are, it would be much easier and quicker for the company to create this new API if it had a layered API architecture in place. In such a case, it would only need to create a new API in the presentation layer and reuse services in layers below (e.g., business and persistence).
Have you find anything missing or wrong? I am looking forward to hearing about the mistakes.