Feature Request: Safer API Update Mechanism to Prevent Path Collisions

[baustin612]

Problem description

Hello Axway Team,

Our goal is to fully automate our API deployments within a CI/CD pipeline. We need an idempotent process that can handle both the initial creation of an API and its subsequent updates.

Based on our current understanding of the CLI's capabilities, the api import -f true command seems to be the primary tool for this purpose. However, in our multi-team environment, we've identified a potential risk with this approach that we're hoping you can provide guidance on.

Our Challenge Scenario:

1. Team A has a production API named Order-Processing-API deployed with the path /api/orders/v1.
2. Team B, while developing a new API named New-Inventory-Check, unintentionally configures it to use the same path: /api/orders/v1.
3. Team B's CI/CD pipeline runs its deployment using api import -c new-inventory-check.json -f true.
4. Potential Outcome: The -f true flag could cause Team B's deployment to overwrite Team A's existing API, leading to a service disruption.

To manage this risk, our current solution is a custom pre-flight check workflow that runs before every deployment. This workflow uses apim api get to fetch the current state of the gateway and then manually checks for path collisions where the API names do not match.

This leads to our main question: Is there a recommended, built-in method within the APIM CLI to safely handle updates in a way that prevents this type of path collision?

Feature request

If a built-in method for our scenario does not currently exist, we would like to propose a feature that we believe would be highly valuable for users in automated enterprise environments.

Proposed Solution:

We suggest a new flag for the api import command, for example --safe-update or --strict-force, that would provide a safer update mechanism.

Example Usage:
apim api import -c config.json --safe-update

Expected Behavior for this New Flag:

The CLI would perform the following logic internally:

1. Check if an API with the same path already exists on the gateway.
2. If an API with that path is found, the CLI would then compare the name from the local configuration file with the name of the existing API.
3. Collision Detected: If the names do not match, the command should fail with a clear error message (e.g., "Error: Path /api/orders/v1 is already in use by a different API named 'Order-Processing-API'.")
4. Valid Update: If the names do match (or if the API is identified by its apiId in the config), the update should proceed.
5. New API: If no API with that path exists, it should be created.

Thank you for your time and any guidance you can offer on this matter.