API Connect components

The API Connect components provide a unified user experience across the API lifecycle. Changes in one stage of the API lifecycle are automatically reflected in the other components of API Connect.

The following diagram depicts the API Connect components, summarizes the key functions of each component, and illustrates how the components interact. The components are further described in the sections that follow.
API Connect components

Cloud Manager

The API Connect Cloud Manager component is used to manage the API Connect on-premises cloud. The Cloud Administrator uses this UI to:
  • Define the cluster of Management servers, Gateway servers, and containers that are required in the cloud, and configure the topology. For information about Management servers and Gateway servers, see API Connect server requirements. For information about containers, see Application runtime/Containerized runtime/API Connect Collective.
  • Manage (modify, move, remove, restart, reboot) the servers in the cloud.
  • Monitor the health of the cloud.
  • Define and manage the provider organizations that develop APIs. (Assigned managers or owners of provider organizations can also complete this task.)
  • Define additional cloud administrators, or set up users with roles that enable access to specific capabilities.
  • Add user registries for authenticating users and securing APIs, and configure the secure transmission of data (for example, through websites).

For more information about the Cloud Manager, see Managing your cloud.

The developer toolkit

The developer toolkit provides the tools for modeling, developing, and testing APIs and LoopBack® applications. The developer toolkit includes a command line interface (CLI) and a corresponding graphical user interface, the API Designer. It incorporates LoopBack, an open source Node.js framework.

API developers use the API management functions in the API Designer or the CLI to create draft API definitions for REST and SOAP APIs, or for OAuth provider endpoints that are used for OAuth 2.0 authentication. The API definitions can be configured to add the API to a Product, add a policy assembly flow (to manipulate requests/responses), and to define security options and other settings. APIs can then be tested locally prior to publishing, to ensure they are defined and implemented correctly.

Using LoopBack, an API developer can create a Node.js application, connect to a data source such as a back-end database or a REST API to be consumed, and then expose the application as a REST API by creating a model definition. A LoopBack model defines the application data, validation rules, data access capabilities, and business logic for an API, and provides a REST API by default. This REST API can then be used by a REST API definition that was created using the API Designer or CLI and exposed to your users. The API and its associated application, which are implemented as a LoopBack project, must both be published to enable the project to be run. LoopBack projects can also be tested locally. The following diagram illustrates the LoopBack project architecture:
The LoopBack project architecture.

[V5.0.7 or later]Draft APIs (in their containing Products) that are created using the API Designer, CLI, or LoopBack are published to Catalogs. Applications created using LoopBack are published to containers or to an API Connect collective, from where they run when called. (For information about containers and collectives, see Application runtime/Containerized runtime/API Connect Collective.)

[V5.0.6 and earlier]Draft APIs (in their containing Products) that are created using the API Designer, CLI, or LoopBack are published to Catalogs. Applications created using LoopBack are published to an API Connect collective, from where they run when called. (API Connect Collective is a separate, installable component of API Connect and is described in Application runtime/Containerized runtime/API Connect Collective.)

The developer toolkit is installed locally, for offline API and application development. For more information about the developer toolkit, see Developing your APIs and applications. For more information about LoopBack, see LoopBack: The Node.js API Framework.

API Manager

The API Manager provides a user interface that facilitates promotion and tracking of APIs that are packaged within Products and Plans. API providers can move the Products through their lifecycle, and manage the availability and visibility of APIs and Plans.

Catalogs and Spaces are created in the API Manager to act as staging targets through which APIs, Plans, and Products are published to developer organizations. API providers can stage their Products to Catalogs or Spaces, and then publish them to make the APIs in those Products visible on a Developer Portal for external discovery.

To control access to the available API management functions, users in the provider organization can be set up in the API Manager UI with assigned roles and permissions. API providers can also use the UI to manage the developer organizations that sign up to access their APIs and Plans. Developer communities can additionally be created as a way of grouping together a collection of developer organizations to whom a particular set of Products and Plans can be made available.

The API Manager UI also includes functions to manage the security of the API environment, and provides access to analytics information about API invocation metrics within customizable dashboard views.

Note: The API Manager includes the ability to create and edit APIs. However, the preferred practice is for these tasks to be performed by using the toolkit CLI or API Designer UI, which are provided in the developer toolkit component.

For more information about the API Manager, see Managing your APIs.

API Gateways

Gateways enforce runtime policies to secure and control API traffic, provide the endpoints that expose APIs to the calling applications, and provide assembly functions that enable APIs to integrate with various endpoints. They also log and report all API interactions to the API Connect analytics engine, for real-time and historical analytics and reporting. Two types of Gateway are available for use in API Connect:
  • Micro Gateway only The Micro Gateway is a Gateway that is built on Node.js, for use by developers and single departmental projects, and it provides enforcement for the authentication, authorization, and flow requirements of an API. The Micro Gateway provides a limited set of API policies for security and traffic management. The Micro Gateway is deployed on an API Connect collective and supports a single Catalog per instance or cluster.
    Important: IBM® API Connect Micro Gateway is deprecated in IBM API Connect Version 5.0.8 in favor of DataPower® Gateway. From 1 April 2020, Micro Gateway, and associated toolkit CLI commands, will no longer be supported. Existing users can migrate their API definitions to IBM DataPower Gateways. For information on supported API policies, see Built-in policies.
  • DataPower Gateway only The DataPower Gateway is an enterprise API Gateway that is built for departments and cross-enterprise usage. This Gateway provides a comprehensive set of API policies for security, traffic management, mediation, acceleration, and non-HTTP protocol support. The DataPower Gateway is deployed on a virtual or physical DataPower appliance and supports multiple Catalogs per instance or cluster. The DataPower Gateway has more policies available to it than the Micro Gateway and can handle enterprise level complex integration. DataPower Gateway supports containers for flexible runtime management.

Your API Connect offering (or edition) can include a Micro Gateway only, or both a Micro Gateway and virtual DataPower Gateway. Support for a physical DataPower Gateway is also available, subject to certain conditions. For more information about the API Connect offerings, see API Connect offerings.

Application runtime/[V5.0.7 or later]Containerized runtime/API Connect Collective

You can run applications and API implementations in API Connect Collectives () or application containers.
[V5.0.7 or later]Note: API Connect Collective is deprecated in API Connect V5.0.7.
Application runtime

The application runtime provides a runtime environment for executing APIs in API Connect.

[V5.0.7 or later]Containerized runtime
[V5.0.7 or later]A containerized runtime environment provides a lightweight deployment location for APIs and applications. A container wraps an application in a complete file system that includes everything it needs to run, such as code, runtime, system tools, and system libraries. You can use Docker Swarm or Kubernetes containers to run your APIs and applications being managed by API Connect. For more information, see Installing a containerized runtime environment.
API Connect Collective

In an on-premises environment, the API Connect Collective component additionally provides a collection of runtime environments for executing LoopBack applications that are created using the developer toolkit.

In API Connect, a collective is used to deploy and run LoopBack applications and the Micro Gateway (which itself is created as a LoopBack app). A collective is an administrative and operational domain for a collection of servers. In this context, a server refers to a LoopBack application, which is packaged as an application server for deployment to the collective. When a LoopBack application (server) is published to a collective, it must be joined to the collective, which then makes that application server a collective member. A collective member is the runtime for a deployed application. The collective members for each deployed application run on a member host, which is a machine that is set up to run servers in a collective, has an SSH daemon installed, and is registered with the collective.

The collective members are managed by a collective controller, which is a (WebSphere Application Server) Liberty Network Deployment Java server that maintains the state of the collective. The collective controller runs on a controller host machine. The collective controller acts as a centralized control point for the collective to perform operations such as file transfer and cluster management, and includes storage and collaboration capabilities. More specifically, the collective controller is responsible for deploying a published LoopBack application as a server on the member host (using SSH), joining the server to the collective (to make it a collective member), and then starting the server so that the application can run.

The collective controller and collective members use HTTPS for bidirectional communication. The collective members share information about their network location, security details, and operational status, which ensures that information can be readily retrieved without having to invoke an operation on each individual member. The collective controller also periodically monitors the health of the servers to see if they need to be restarted. The controller publishes information about the member applications to the Micro Gateway and to the DataPower Gateway (using an On Demand router), so they know what applications are available to route to. The collective also provides a Liberty Admin Center UI console on the collective controller, which can be used to monitor the collective. The Admin Center is accessible from the API Manager UI with read-only access. API Connect clients that run software processes can also connect to the collective controller to query for information about the collective and its membership, or to perform operations.

A collective can be configured with one or more collective controllers, depending on scalability and high availability requirements, and can have multiple member hosts. The collective controller and collective members can also either be on separate hosts or on the same host. For more information about collectives, see Liberty: Collective architecture in the WebSphere Application Server Liberty Network Deployment documentation.

The following diagram depicts the architecture for an API Connect collective to which the Cloud Manager and API Manager connect. The collective controller is on a separate host from the three collective members.
Architecture for an API Connect collective

To enable communication between a collective and the other API Connect components, the collective and collective controller must be registered within the Cloud Manager.

Developer Portal

The Developer Portal provides a customizable self-service web-based portal to application developers to explore, discover, and subscribe to APIs.

When API providers publish APIs in the API Manager, those APIs are exposed in the Developer Portal for discovery and usage by developer organizations. Application developers can access the Developer Portal UI to register their applications, discover APIs, use the required APIs in their applications (with access approval where necessary), and subsequently deploy those applications.

The Developer Portal provides additional features, such as forums, blogs, comments, and ratings, for socialization and collaboration. API consumers can also view analytics information about the APIs that are used by an application, or used within a developer organization. For more information, see Developer Portal: discover and use APIs.

API Connect server requirements

From an on-premises cloud, you can create, promote, use, and track APIs. An on-premises cloud is composed of various appliances, where each appliance is a server of a specific type. The collection of servers defines your cloud and determines how to distribute the work of managing, analyzing, routing, and storing data.

Your on-premises cloud can be a combination of new and existing physical appliances and virtual appliances or can be entirely composed of virtual appliances. The type and quantity of servers in an API Connect environment are determined by the individual needs of each enterprise, but the minimum requirement is one Management server, one Gateway server, and one server to host the Developer Portal.

The API Connect on-premises cloud includes the following server types:
  • Management server. Stores all of the cloud configuration, and controls communication between the other servers within API Connect. Manages the operations of the various servers in the API Connect cloud and provides the tools to interface with the various servers. The Management server also provides analytic functions that collect and store information about APIs and API users. The Cloud Manager and API Manager user interfaces run on the Management server.
  • Gateway server. Processes and manages security protocols and stores relevant user and appliance authentication data. The Gateway server also provides assembly functions that enable APIs to integrate with various endpoints, such as databases or HTTP-based endpoints. The Gateway types include a Micro Gateway and a DataPower Gateway.
  • Developer Portal server. Provides a customizable social developer portal with a full-featured content management system, and includes clustering capability. Enables API providers to build portals for their application developers, and provides the interface for application developers to discover APIs and subscribe to usage Plans contained in the published Products for use in their applications.
Note: All Management appliances in an API Connect cloud must run at the same firmware level as each other. Gateway appliances can run on different firmware levels to each other, but it is recommended that all of the Gateway appliances run on the same level as each other.
Table 1. Minimum firmware requirements to run in an API Connect cloud
Server Type Min. Required Firmware Version Supported Hardware
Management server IBM API Connect Version 5.0 Not applicable
Gateway server IBM DataPower Gateway

Version details are provided in the Supported Software section of the IBM API Connect Version 5.0 Detailed System Requirements report on the IBM Software Product Compatibility Reports site for each API Connect offering:

(the following links display the Detailed System Requirements report for the latest version. If you want to see the report for an earlier version, open the Detailed system requirements for a specific product page, search for the IBM API Connect product, then select the required offering and version)
Important: The Application Optimization (AO) option is required. Ensure that the AO module is activated.
See the Supported Software section of the IBM API Connect Version 5.0 Detailed System Requirements report for each API Connect offering:
(the following links display the Detailed System Requirements report for the latest version. If you want to see the report for an earlier version, open the Detailed system requirements for a specific product page, search for the IBM API Connect product, then select the required offering and version)
Developer Portal IBM API Connect Developer Portal Version 5.0 Not applicable

For more information about planning your cloud, see Planning your cloud.

Typical tasks per interface component

API Connect offers both command line and graphical user interfaces. Provider and developer organizations use different interfaces for completing typical tasks. Refer to the table below to locate the interface that corresponds to a specific task.

Table 2. API Connect Tasks per interface component
Organization Type Interface Component Tasks
API Provider Command Line Interface (CLI) Create APIs, Plans, and Products
API Designer UI Create APIs, Plans, and Products
API Manager UI Create Catalogs and Spaces; Create Developer Organizations
Cloud Manager UI Create Provider Organizations
API Consumer (application developer) Developer Portal Access APIs to create and run applications; Create Developer Organizations
  • If self-service onboarding is enabled for a Catalog, a developer organization is automatically created when an application developer signs up or is invited by the API provider to a Developer Portal, and the application developer then becomes the owner of that developer organization.

    For more information about the API Connect components, see API Connect components.