Today, we at pleased to announce the general availability of Versions & Revisions in Azure API Management. This feature lets customers:
- Present groups of related APIs to your developers. Versions differentiate themselves through a version number (which is a string of any value you choose), and a versioning scheme (path, query string or header).
- Make changes to your APIs in a controlled and safe way. When you want to make changes, create a new revision. You can then edit and test API without disturbing your API consumers. When you are ready, you can then make your revision current – at the same time, you can post an entry to the new change log, to keep your API consumers up to date with what has changed.
Read more about the feature in our original announcement for public preview. With general availability, in addition to a host of stability fixes, there are additional updates:
Manage version sets
In our preview, version sets (the top level grouping of your versioned APIs) were managed transparently. We have added a new screen that allows you to manage version set display name and description, and see the versioning scheme applied to the set (changing scheme is currently only available through the Management API – and should be done with extreme caution). To see it, select the version set in the left navigation panel of the API design screen.
Markdown support for change log entries
When making an entry to the API change log, customers can now use Markdown to add formatting to their entries.
Support for SOAP/Non SOAP APIs within the same version set
Customers can now run SOAP and REST APIs together as versions of an API. So for example, a customer could create a SOAP pass-through API as version 1, and then create a SOAP-to-REST API of the same backend service as version 2.
Azure Resource Manger API support
Versions & Revisions are now fully supported through the ARM API.
Policy expression support
Access to Versions & Revisions is now available through policy expressions. This allows customers to write policies that, for example, changed the backend if the call came in to a particular revision or one that was not current. See properties for Version, Revision and IsRevisionCurrent on the context.Api object.