As APIs open doors to information and functionality, they move well beyond being merely technical interfaces to becoming central actors in new digital business models. However, for such business models to be effective and successful, technical teams are confronted with the unique challenge of API-enabling systems that weren't necessarily built to provide real-time access. Because of this, there are several implementations beyond the obvious that must be catered for in order to create APIs that are easy to use and can truly scale to handle the sort of volumes expected from real-time systems.

This article is an excerpt from the book Enterprise API Management written by Luis Weir. This book explores the architectural decisions, implementation patterns, and management practices for successful enterprise APIs. This article elaborates on the core concepts and capabilities required to implement API-led architectures.

You may also like:  API-Led Connectivity

API-led is an architectural approach that puts APIs at the epicenter of communications between applications and the business capabilities they need to access, in order to consistently deliver seamless functionality across all digital channels. The following diagram, for example, illustrates how an API Exposure capability, like an API Gateway, can provide access to APIs that can be consumed to leverage different business capabilities.

Furthermore, because APIs can directly and/or indirectly drive revenue generation, the department that delivers them can evolve from being a cost center to potentially becoming a profit center. In other words, an API becomes a first-class business citizen, as opposed to a necessary evil, which is often how integration is perceived by businesses. Long story short, APIs become products in their own right and thus require the same level of design thinking, ongoing attention, and evolution as other business products.

Architecting API-led

Doors are used as a metaphor to articulate the role of APIs in delivering access to enterprise information assets and functionality, or in business terms, business capabilities. However, just like doors, which come in different types, materials, and sizes often determined by what sort of access they provide, APIs can be classified in different types as well.

For example, some APIs might be built with a specific use case in mind and in support of a specific application. Because of this, such APIs can be quite specialized and tailored for the purpose they were built to serve. In order words, they are of single purpose and not suitable for reuse outside the context they were built for.

A common term used to refer to these types of [single purpose] APIs is Experience APIs, mainly because of their role in enabling applications that humans directly interact with (for example, mobile apps, web apps, and so on). However, not all applications that require specialized-purpose APIs have to interact with humans. For example, in Industry 2.0, APIs may be built in support of modern industrial lines, or in farming and agriculture, drones are being used as a means to scan soil conditions across large areas of land, and APIs are used to obtain and send data in real time.

Other APIs, however, might be built specifically with reuse in mind. Such APIs will be more generic in nature and won't be tied to a particular use case. Therefore, these APIs are multi-purpose, meaning they can be used in a variety of scenarios and thus should be able to serve many applications. The following diagram illustrates that APIs that don't provide access to tailored business capabilities can be consumed by many applications to address different use cases.

Just understanding the different types of APIs isn't enough for architecting API-led solutions. A robust architecture must always be reflective of a solid understanding of the business domain in question and the capabilities required in order to address it. In the context of enterprise-grade APIs, at the most basic level, API-led architecture should address things like:

• Securing APIs from unauthorized access and major security threats
• Ensuring that Consuming Applications can always find the right API endpoint
• Throttling and/or limiting the number of calls made to an API to ensure continuous availability
• Supporting capabilities such as API design, testing, continuous integration, life cycle management, monitoring, and operations, to name a few
• Error handling and preventing error propagation across the stack
• Real-time monitoring of APIs with rich analytics and insight
• An approach for implementing scalable and flexible business capabilities, for example, in support of Microservices Architectures

In the subsequent sections, a top-down approach for elaborating an API-led architecture is presented. It starts by first defining conceptually the core building blocks of the architecture and describing their purpose. It then continues by defining the individual capabilities required by each block in more detail in order to accomplish its purpose. Finally, the section illustrates how all capabilities hang together cohesively as a single but modular platform.

The Conceptual Architecture View

The conceptual API-led view defines the main building blocks of the architecture, along with their purpose and responsibility. As in Figure 3, the conceptual API-led architecture consists of four main building blocks, plus the Consuming Applications. Horizontal blocks represent core runtime capabilities, without which implementing APIs would not be possible. Vertical blocks represent important supporting capabilities geared towards life cycle support, management, operations, and analytics.

Consuming Applications are considered as any computer program capable of calling and making use of an API. In real-world terms, these may vary from traditional commercial off-the-shelf applications (for example, commerce systems), to web applications, mobile applications, wearable devices, and even more sophisticated things such as drones and smart cars.

The API Exposure building block, as the name implies, is responsible for securely and reliably exposing access to API endpoints.

Services are units of software that deliver well-defined and bounded functionality. Such functionality is referred to as a Business Capability because it means something to the business and the function the service delivers can be mapped to a business process. Therefore, in order to deliver such functionality, a service must be capable of implementing business logic, data transformation and validation, business rules, orchestrations and/or choreographies to name a few. Services expose their functionality via API endpoints that are not accessed directly but mediated via the API Exposure layer.

The Management & Operations block consists of capabilities in aid of the end-to-end life cycle management of APIs, including, but not limited to, API design and mocking, policy implementation, deployment, promotion, runtime operations, and analytics, deprecation and retirement. Developer-centric capabilities such as API pages, a developer portal for API discoverability and subscription, and application keys management also form part of this building block. These building blocks act as aids when monetizing APIs, as it's responsible for collecting important metrics that might be required when billing APIs based on usage.

Lastly, the Identity and Access block refers to capabilities in support of users, roles, and access management features. For example, from a life cycle and operations perspective, this block enables different users (API product owners, administrators, designers, and developers) to seamlessly log-on to the API management console and/or API developer portal using existing enterprise credentials. It also restricts access to different areas depending on the user role. From an API Exposure perspective, this block aids authentication and authorization policies by, for example, enabling tokens (for example, OAuth 2.0, OpenID and/or even SAML) to be generated and enforced at runtime.

Summary

This article began by delivering a comprehensive overview of what API-led architectures actually are, including a detailed explanation of the fact that there isn't one, but at least two main types of APIs: single-purpose — focused on delivering tailored functionality in support of a specific and well-known digital experience, and multi-purpose — a more generic functionality aimed at solving many use cases (most of which are probably not known at the time the API is conceived).

The article then continued to explain that APIs are like doors but to information and functionality, and that these doors (the APIs) are accessible through a set of API Exposure capabilities, responsible for providing fast, secure, and reliable access to such assets.

Create API strategies to deliver business value with Luis Weir’s upcoming release Enterprise API Management.