Azure API Management

Inside scoop from the API Management team

Release notes – August 23, 2017

On Wednesday, August 23, 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

  • Versions and revisions (yay!) give you flexibility in how you manage change and your API lifecycle. We will turn on this feature (in preview) for everyone after we finish upgrading all production tenants. We will make a separate announcement when that happens.
  • Now Premium customers, using multi-region deployment feature, can direct API requests to a specific location using regional endpoints in the format below and thus can implement a broad range of custom traffic management scenarios. The value of the region-name is derived from a name of an Azure region by removing spaces and converting to lower case e.g., “East US” corresponds to “eastus”.
    {serviceName}-{region-name-withoutspace-lowercase}-01.regional.azure-api.net
  • We added Azure resource name property to the Add API pop-up. It’s auto derived from the API display name but can also be set explicitly.
  • We added “ProtocolViolation” value to the context.LastError.Reason.
  • We introduced an advanced policy that controls concurrency of a group of policies. Unlike rate-limiting policy, it doesn’t throttle callers when a threshold is achieved but rather queues up the requests. Callers receive back off errors only after the queue reaches a specified length limit. All the details are here. Here is what the new policy looks like:
    <limit-concurrency key="…" max-count="…" timeout="…" max-queue-length="…">
    … nested policies …
    <limit-concurrency>
  • We can now import certificates from Azure Key Vault. The feature is immediately available via ARM templates. Support in the management API and Azure portal will follow. To take advantage of Key Vault integration you need to pass a parameter in a template as shown below. More details can be found here.
    "parameters": {
    "proxyCustomHostnameBase64EncodedPfxCertificate": {
    "reference": {
    "keyVault": {
    "id": "/subscriptions/{subscription-id}/resourcegroups/{resource-group}/providers/Microsoft.KeyVault/vaults/MyVault"
    },
    "secretName": "MySslCertSecret"
    }
    }
    }
  • Premium tier customers with multiple hostnames can now designate one of the certificates as default (the one for b.contoso.net in the example below) and we will use it to respond to requests that don’t specify an SNI header:
    ...
    "hostnameConfigurations": [
    {
    "type": "Proxy",
    "hostname": "a.contoso.net",
    "encodedCertificate": "Encoded Base 64 Certificate issued to Subject a.contoso.net",
    "defaultSslBinding": "false"
    },
    {
    "type": "Proxy",
    "hostname": "b.contoso.net",
    "encodedCertificate": "Encoded Base 64 Certificate issued to Subject b.contoso.net",
    "defaultSslBinding": "true"
    }
    ]
    ...
  • Premium tier customers can now choose Australia for secondary regions without having a primary region located there as well.

Updates and fixes

  • We fixed a regression where switching Developer portal locale had no effect.
  • We removed extra slashes appearing in the URLs of APIs with empty suffix.
  • We tightened up API console’s security.
  • With Service Fabric backends we now always perform name resolution on initial connection failure.
  • With Service Fabric stateless backends we try other instances before attempting name resolution.
  • We refreshed IP-to-location data set to improve the accuracy of the reports.