Working with Catalogs

Products must be staged to a Catalog and then published to Developer organizations to become available to application developers. In IBM API Connect, you can create multiple Catalogs. Catalogs are useful for separating Products and APIs for testing before you make them available to Developer organizations. [V5.0.5 or later]The syndication feature in IBM API Connect means that you can also publish a Product to a Space in a Catalog.

A Catalog is a staging target, and behaves as a logical partition of the gateway and the Developer Portal. The URL for API calls and the Developer Portal are specific to a particular Catalog. In a typical configuration, an API provider organization uses a development Catalog for testing APIs under development and a production Catalog for hosting APIs that are ready for full use. A common approach is to have a development cloud with a development Catalog, a few test Catalogs and a production cloud that might have its own test Catalog.

[V5.0.5 or later]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.

Types of Catalog

You can apply the following type settings to a Catalog:
[V5.0.2 and earlier]Sandbox
[V5.0.2 and earlier]

Use the Sandbox setting for a development Catalog. In a development Catalog, staging and publishing actions are forced, meaning that if you republish a previously published Product it is overwritten without warning. If conflicts are found, they are automatically resolved by the system. Unpublish actions happen automatically. Furthermore, approvals are bypassed for publishing and lifecycle actions; you cannot configure the Catalog to require approval. Pending approvals are canceled when a non-development Catalog is converted to a development Catalog.

By default, a development Catalog is provided for you. A development Catalog must be used only for test purposes. When you use the test tool in a development Catalog, any Product that you test is forced through and overwrites staged and published Products even if the operations are being used on the Developer Portal. A Developer Portal created from a development Catalog must be used in the same way, that is, for testing purposes only and not for real cases.

[V5.0.3 or later]Development
[V5.0.3 or later]

In a development Catalog, staging and publishing actions are forced, meaning that if you republish a previously published Product it is overwritten without warning. If conflicts are found, they are automatically resolved by the system. Unpublish actions happen automatically.

Note:
  • [V5.0.4 and earlier]In a development Catalog, approvals are bypassed for publishing and lifecycle actions; you cannot configure the Catalog to require approval. Pending approvals are canceled when a non-development Catalog is converted to a development Catalog.
  • [V5.0.5 or later]A development Catalog behaves the same as any other Catalog with regard to requiring approval for staging and publishing actions, if the Catalog has been configured to require approval.

By default, a development Catalog is provided for you. A development Catalog must be used only for test purposes. A Developer Portal created from a development Catalog must be used in the same way, that is, for testing purposes only and not for real cases.

[V5.0.4 and earlier]When you use the test tool in a development Catalog, any Product that you test is forced through and overwrites staged and published Products even if the operations are being used on the Developer Portal.

[V5.0.3 or later]Automatic subscription
[V5.0.3 or later]
If you enable automatic subscription for a Catalog, testing of your APIs in the API Manager user interface is made easier because a test application is used, with a pre-supplied client ID and client secret, which is automatically subscribed to all the Plans in the Catalog, so you don't have to specify a plan or application when testing. The test application is not subject to rate limits. Automatic subscription is available only for a development Catalog.
[V5.0.3 and earlier]Note: Automatic subscription is supported only with the DataPower® Gateway.
Default
You can set one of your Catalogs to be the default Catalog. Then, calls to APIs that are published to that Catalog can use a shorter URL that does not include the Catalog name.

For more information on using the Developer Portal, see Discovering and using APIs.