Related thoughts: App Service Git deployment does not impose the same 30-day limit on Git-compatible keys.
Read-only keys would be helpful as well. Our use case does not require us to deploy with git, only clone for validation purposes.
294 votesunder review · 7 comments · API Management » Service management · Flag idea as inappropriate… · Admin →
Adding to what I just wrote below, I'd also like access to Newtonsoft.Json.Linq. That gives me access to the JObject.ContainsKey extension method that I'd like to use to verify incoming json, sans the ability to use schema validation.
Short of full fledged Schema validation, giving us access to the namespace "Newtonsoft.Json.JsonSerializerSettings" would make it easier to do some validation in policy statements.
Regarding my suggestion below, another approach would be to define groups that are associated with a specific rate limit, and have keys be members of one defined group.
We are looking to rate limit IOT devices, owned by our customers, that send data to our servers. The data would be sent via REST requests, and the key that the rate limit would be applied to would likely be in a header.
We would like to be able to apply a separate rate limit per key. We don't currently have that ability with policy statements like "rate-limit-by-key", as that only allows us to assign a global rate limit per header name, rather than header value.
I can imagine a separate interface in APIM's Portal UI that allows for key management. In that interface, we'd be able to generate a new key, and define its rate limit.
Please see http://aka.ms/apimdevops for (work in progress) guidance and tools around automating deployment across multiple API Management environments.
We want this for a different reason. Our company has an organization in Github, and all of our source-controlled assets are in private repos that belong to that organization. Having a separate git repo just for APIM adds complexity to our workflow that we'd like to avoid. It would be ideal to be able to tie an APIM instance to a dedicated private Github repo that belongs to our organization.