Managing API Products

Here's an example of using the products and apis commands through a full lifecycle:

Note: If the OpenAPI (Swagger 2.0) file that defines your API uses a $ref field to reference a fragment of OpenAPI (Swagger 2.0) code that is defined in a separate file, the $ref field is replaced with the contents of the target file before the product that contains the API is staged or published with the apic publish command. For more information, see Using $ref to reuse code fragments in your OpenAPI (Swagger 2.0) files.

Here's an example of a more complex lifecycle where a new version of a Product and API replaces the original version at runtime.

Set the default Catalog and login to the mgmnthost.com API Connect cloud:

apic config:set catalog=apic-catalog://mgmnthost.com/orgs/climbon/catalogs/sb
apic login --username some-user --password some-password --server mgmnthost.com

Create and publish an initial version:

apic create --type api --title Routes --version 1.0.0 --filename routes100.yaml
apic create --type product --title "Climb On" --version 1.0.0 --apis routes100.yaml --filename climbon100.yaml
apic publish climbon100.yaml

Create a new version to fix a bug in the API, stage it to the Catalog:

apic create --type api --title Routes --version 1.0.1 --filename routes101.yaml
apic create --type product --title "Climb On" --version 1.0.1 --apis routes101.yaml --filename climbon101.yaml
apic publish --stage climbon101.yaml

Inspect the Catalog:

apic products
apic products:get climbon:1.0.0
apic products:get climbon:1.0.1

"Hot-replace" version 1.0.0 with 1.0.1:

apic products:replace climbon:1.0.0 climbon:1.0.1 --plans default:default

In addition to the lifecycle management capabilities, you can download Products and APIs in Catalogs using the pull and clone sub-commands:

It can also be useful to clear all products and their APIs from a Catalog, particularly for a development Catalog (you must provide the name of the Catalog as the value of the --confirm parameter):

apic products:clear --confirm catalog_name

You can use a Space to partition a Catalog so multiple teams can manage Products and APIs independently in a single Catalog. A Space is conceptually like a sub-catalog, except that Products and APIs in all Spaces in a given Catalog are published to the same developer portal. For more information about Spaces, see Using syndication in IBM API Connect®.

apic catalogs:set catalog_name --spaces enabled

If Spaces are enabled for a Catalog, Products can be staged and published only to a Space within that Catalog. To publish to a Space, the --scope space option must be included in the publish command, for example:

apic publish --scope space product.yaml --space space --catalog catalog --organization organization --server server

where

• product is the name of the product that you want to publish.
• space is the name of the Space to publish to.
• catalog is name of the Catalog that contains the Space.
• organization is the name of the organization.
• server is the management server; portnumber is optional (default is 443).

apic products --scope space --space flights --catalog production --organization climbonorg --server mgmnthost.com