Packaging strategy and terminology in API Connect

API Connect uses a proprietary packaging strategy for creating and publishing collections of APIs.

The packaging strategy supports API providers in meeting the requirements of the API consumers. An understanding of the concepts and terminology behind the packaging strategy is required before developing and deploying APIs using IBM® API Connect.

The following sections describe the concepts and terminology behind the packaging strategy for IBM API Connect:

APIs

An Application Programming Interface (API) is an industry-standard software technology. An API is a set of routines, protocols, and tools for building software applications. An API specifies how software components interact and provides quick access to common assets and processes. APIs can be public (such as offered on GitHub), can require client credentials, or can be kept private within an application. Thus, APIs are classified as external (public), partner (protected), or internal (private), based on how they are consumed.

An API is composed of operations, called methods, which are offered in one of the following styles in API Connect:
  • A REST API is structured according to the principles of Representational State Transfer. REST APIs use HTTP or HTTPS requests to PUT, GET, POST, and DELETE data (also referred to as CRUD operations). REST identifies resources using URIs. Data can be described in a variety formats (XML, HTML, JSON, TXT, etc.), with JSON being the popular choice. REST APIs specify MIME (Multipurpose Internet Mail Extensions) types. REST is platform- and language-independent and works across firewalls using HTTPS. REST APIs leverage HTTP standards for security, caching, and status codes. HTTP clients and servers are available for all major programming languages and operating system/hardware platforms. REST implementations are easily scaled due to use of HTTP and browsers as a uniform interface.
  • A SOAP (Simple Object Access Protocol) API is a web service that is exposed as an API. SOAP interfaces are described in WSDL (Web Services Description Language) format. The WSDL is an XML document describing the structure for headers, messages, URL endpoints, and datatypes used to access a web service. SOAP is considered more secure than REST as it supports WS-Security as well as SSL. SOAP also contains WS-Reliable Messaging for reliability, rather than relying on retrying the operation (as does REST). SOAP requires a client application and is better suited for enterprise applications that require secure transactions.

APIs can be versioned and packaged into multiple Products for distribution to API consumers on the Developer Portal. For information about creating and managing APIs, see Developing your APIs and applications and Managing your APIs.

Plans and products

Plans and products are proprietary packaging constructs that are unique to API Connect. API providers use products to offer one or more APIs to the application developers who will consume the APIs (API consumers). The providers use Plans to control access to APIs and to manage API usage. Products are packages that contain both the APIs and the accompanying Plans. See Working with Products.

To make an API available to an application developer, it must be included in at least one product and at least one plan.

Plans perform the following functions:

  • Control which APIs an application developer can use
  • Make available a collection of operations from one or more APIs
  • Apply rate limits to APIs to differentiate between offerings
  • Implement different rate limits to specify how many requests a consuming application is allowed to make during a specified time interval

A rate limit can be implemented as a default rate that is shared across all operations in a plan, or can be set for specific operations of an API. Plans can use differing rate limits to provide different levels of service to API consumers. For example, a Demo Plan might enforce a rate limit of ten calls per minute, while a Full Plan might permit up to 1000 calls per second.

A product in API Connect bundles a set of APIs and Plans into one offering that is intended for a particular use. You can create plans only within products, and these products are then published in a Catalog. The following rules apply for the relationship between products and plans:
  • A plan can belong to only one product.
  • A product can have multiple plans that each contain a different set of APIs.
  • A plan in one product can share APIs with plans from any other product.
Multiple plans within a single product provide different levels of performance for the same offering. For example, a product can include a Demo Plan that makes a single API available, and a Full Plan that makes several APIs available.
The following diagram illustrates how plans can be used to make operations from one or more APIs available, and to set rate limits on both plans and individual operations:
Selection of operations and rate limits in a plan
The diagram illustrates the following concepts:
  • Product A contains two APIs and two plans.
  • Both APIs are included in Plan A1.
  • Plan A2 includes only API 2, which is also included in Plan A1. Operation 2a for API 2 is excluded from Plan A1. All operations in API 2 are included in Plan A2.
  • Different rate limits are set for the two plans at the plan level. For API 2 in Plan A2, a rate limit is also set specifically for Operation 2c to override the rate limit set at the Plan level.

Products are used to manage the lifecycle of the APIs they contain. The states in the Product lifecycle include draft, staged, published, deprecated, and retired. A product in draft state is moved to the staged state when it is staged to a Catalog. A product moves to the published state when the product is published. The APIs in a product become accessible to API consumers when the product is in the published state and they then become visible on a Developer Portal. After a product is published, application developers can use the Developer Portal to gain access to its APIs by registering applications to one or more plans in the product.

The following diagram illustrates the hierarchy of Products, Plans, and APIs.
Hierarchy of Products, Plans, and APIs

For more information about managing the lifecycle of products, see Working with Products in the API Manager.

Catalogs and Spaces

A Catalog contains a collection of products. Catalogs are staging targets through which products (together with the accompanying plans and APIs) are published on a Developer Portal. Catalogs are used to separate products and APIs for testing before publishing them on a Developer Portal. In a typical workflow, an API provider uses a development Catalog when developing and testing APIs, and uses a production Catalog for publishing APIs that are ready for external use. Each Catalog has an associated Developer Portal for exposing the published products. A Catalog includes runtime capability through an associated gateway service that handles any API requests for the APIs in that Catalog.

API Connect includes a syndication feature that enables API providers to partition a Catalog into multiple staging targets (or Spaces) for API development purposes. Each API provider development team can use its own dedicated Space to manage its products independently of other teams. A Space has its own set of capabilities relating specifically to the products and APIs that are created and published to that Space. Products and APIs in all Spaces in a given Catalog are published to the same Developer Portal. Spaces are not visible on the Developer Portal. Application developers who consume the APIs on the Developer Portal are unaware of the Space configuration used by the API Developers. On the Developer Portal, the APIs are seen as a coordinated offering within a Catalog.

For more information about Catalogs and Spaces, see Working with Catalogs and Using syndication to partition Catalogs into Spaces.

Organizations and users

In the context of API Connect, there are two types of organizations: provider and consumer. An organization can encompass a project team, department, or division.

A provider organization owns APIs, and associated Plans and Products, and can additionally own provider applications that are called by APIs. To complete the various functions in the API lifecycle, a provider organization assigns responsibilities for certain tasks. Some standard responsibilities within a provider organization include:
  • A provider organization owner who has the full set of access permissions to API Connect functions, and can also commission APIs and track their business adoption.
  • API developers who design and develop APIs and applications for the provider organizations to which they belong.
  • An administrator who manages the lifecycles of APIs and publishes APIs for discovery and use.
  • A community manager who manages the relationship between the provider organization and application developers, provides information about API usage, and provides support to application developers.
A consumer organization owns only developer applications, and consumes the APIs and applications produced by the provider organization. Standard responsibilities within a consumer organization include:
  • A consumer organization owner who adds application developers to the consumer organization, views the Products and APIs that the provider organization has made available on the Developer Portal, and subscribes to APIs to use them in applications.
  • Application developers who view the Products and APIs that the provider organization has made available on the Developer Portal, and subscribe to use these APIs in applications.

Users have an existence in the API Connect ecosystem that is independent of an organization. A user can be a member of more than one provider or consumer organization.

There can be multiple provider organizations in one API Connect cloud, to provide an API development environment for each line of business of an enterprise. The API Connect cloud is a collection of servers that comprise an API Connect installation, including the configuration information and metadata that they contain. The cloud infrastructure is shared by all organizations, and managed independently of them (by an IBM Operations team). The following diagram shows the relationship between the provider organizations, consumer organizations, and users.
Diagram showing the relationship between the provider organizations, consumer organizations, and users.

For more information about organizations, see Administering consumer organizations.

Sample provider organization with two Catalogs

The following diagram shows an example for how APIs, Plans, Products, Catalogs, and Spaces fit within provider and consumer organizations. In this example, two Catalogs are created in the provider organization to act as staging targets for different sets of requirements.
  • Catalog 1 does not require separation of the Products for use by individual provider development teams, and so does not have Spaces enabled. API developers with access to this Catalog create draft APIs, and stage and publish them as Products to the Catalog. Several consumer organizations are granted permission to explore, discover, and use the published Products and APIs. In each of the consumer organizations, the published Products and APIs from Catalog 1 are exposed on a single Developer Portal.
  • Catalog 2 is partitioned into two Spaces (X and Y) so that two provider development teams can manage their Products independently. These teams stage and publish their APIs (as Products) separately to the individual Spaces, to make them accessible to application developers in multiple consumer organizations. In each of the developer organizations, the published Products and APIs from both Spaces are exposed in the same Developer Portal, and application developers who access this portal will see the APIs from both Spaces as a coordinated offering.
Hierarchy for organizations, Catalogs, Spaces, Products, Plans, and APIs