An oriole-copse /orders API must keep v1 live while v2 ships a breaking request body. Which APIM construct should the developer use for that breaking change?
Select an answer to reveal the explanation.
Short Explanation
Breaking body change? Use an APIM version so oriole-copse v1 keeps running while v2 ships. Revisions are for safer in-place updates.
Full Explanation
Breaking request-body changes need a new API version in API Management so oriole-copse v1 remains available for existing callers while v2 introduces the incompatible contract. Versions let multiple contract generations coexist using path or query versioning schemes as configured, which is how cities avoid forcing every consumer to upgrade on the same day.
A Git branch on the backend repo alone does not create a gateway-visible version path for callers and does nothing for clients still pointed at the old public URL. Revisions are for safer in-place updates and staged changes to an existing API surface; they are not the construct that keeps a breaking body change side by side as a separate public contract generation. Creating a new storage account per consumer is unrelated to HTTP API versioning and multiplies data silos without solving contract coexistence.
Exam caveat: revisions ≠ versions—revisions track changes within an API lineage; versions publish parallel contracts when wire compatibility breaks.
Operational check: create a v2 version of /orders with the new body schema, keep v1 published and subscribed, route each version to the appropriate backend implementation, and verify legacy clients still succeed on v1 while new clients call v2 with the breaking body.