{{announcement.body}}
{{announcement.title}}

Promoting APIs and API Implementations to Higher Environments

DZone 's Guide to

Promoting APIs and API Implementations to Higher Environments

Working with several customers and one major hurdle several occasions i.e. promoting API to upper environment.

· Integration Zone ·
Free Resource

Working with several customers and one major hurdle several occasions i.e. promoting API to upper environment.

Let's discuss an approach with steps to accomplish better practice for it...

Using DevOps for the deployment of:

  1. API implementations
  2. API instances
  3. API policies
  4. Alerts

And other assets that are required in environments (Staging, Production, etc.), Anypoint Platform favors the promotion of the Anypoint API Manager definition for an API instance from one environment to another i.e., between environments. For example, promote API instance promote from Staging to Production.

Promoting all supported parts of the Anypoint API Manager entry for an API instance does not copy API clients (client applications) to the target environment.

In simple terms that promoted API instances start without any registered API clients.

In the following steps, API consumers must separately request access for their API clients to API instances in all environments-even if the same API and version are requested access to.

Client ID/Secret: 

  • For the API client uses for accessing an API is, furthermore without any dependency of the environment. That is, if the same API client has been granted access to an API instance in the Sandbox and Production environments, it must make API invocations to both API endpoints with the same client ID/secret.
  • An API in the Sandbox environment will be accessible though API instance from the Sandbox environment, and a separate API client in the Production environment to access an API instance from the Production environment. In this case, the two API clients would use distinct client ID/secret pairs, which is preferable for maintenance and governance reasons.

After Promotion:

An API instance in Anypoint API Manager, the newly created/promoted API instance shares the "Implementation URL" and "Consumer endpoint" with the original API instance: this is not realistic and must typically be changed after promotion, such that, e.g., the Production API instance uses Production URLs.

Below is one of the several approaches to promote API to a higher environment...

promote api

Anypoint Runtime Manager follows and favors the similar promotion of Mule applications.

  • Such as API implementations, between environments, As always, DNS names of Mule applications must differ between environments.
  • Promotion of Anypoint API Manager definitions and/or matching API implementations can be automated by as below..
    • Anypoint Platform APIs.
    • The Anypoint CLI which is a command-line interface providing a user-friendly interactive layer on top of Anypoint Platform APIs.

It can be configured by using several ways of the DevOps approach explained as the below image.

anypoint platform

Hope it would help to understand a set approach to follow in API promotion in the Anypoint platform.

It's the power of IPAAS (Anypoint Platform).

Thanks.

Topics:
anypoint platform, api adoption, api application, integration

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}