Azure API Management

Inside scoop from the API Management team

Release Notes – July 14th 2017

On Friday, July 14th 2017, we started deploying a regular service update. We upgrade production service instances in batches, and it usually takes about a week for the rollout to complete.

Below is the list of improvements and bug fixes in this release.

New functionality

  • We now offer full support for Azure Resource Manager (ARM) templates for deploying and configuring Azure API Management. More documentation to follow on this subject, but in the meantime please take a look at example templates for:
  • The following may also be useful:

  • We now support the ability to configure multiple hostnames for your service (Premium tier only). At present, this can be achieved only through ARM (see the “Create with hostname” template above) – support for doing this through the Azure Portal will be added soon.
  • It is now possible to configure a send-request policy with authenticate-certificate or a proxy. Here’s an example:
    <authentication-certificate thumbprint="{thumbprint}" />
    <proxy url="http://localhost:8080" username="aladdin" password="opensesame" />

Updates and fixes

  • We have removed X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version and Server headers from the Developer Portal.
  • Body samples provided to us in an Open API import previously were ignored. This has been fixed.
  • Request/Response Schemas that contained multiple $refs to the same component would sometimes fail to render in the developer portal. These will now render correctly.
  • PublisherEmail and Organisation properties can now be changed only through Azure Resource Manager. We have disabled updating those from the Admin/Publisher Portal. See Update API service.
  • When freeing up a VNET, previously it could take up to 4 hours for this to happen in the case of a failed deployment. Now this should take no more than 30 minutes.
  • WSDL Import will now successfully import and export schemas that use namespaces that are declared at the root of the WSDL document. Errors detected during Schema parsing will now report the specific issue with the schema.