API Management

Microsoft Azure API Management is a turnkey solution for publishing APIs to external and internal consumers. Quickly create consistent and modern API gateways for existing backend services hosted anywhere, secure and protect them from abuse and overuse, and gain insights into usage and health. Plus, automate and scale developer onboarding to help get your API program up and running in no time.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Socket (full-duplex) support in addition to HTTP

    Having the ability to regulate and monitor HTTP services with API Management is great. Wouldn't it also make sense to offer the same for web sockets (or SignalR hubs, etc.) so we can let devs hookup into stream of events (live-data) instead of polling with REST calls?

    1,052 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    28 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  2. Integrate WebHooks

    managing webhooks under api management will get us more control around who is allowed to do what: http://blogs.msdn.com/b/webdev/archive/2015/09/04/introducing-microsoft-asp-net-webhooks-preview.aspx

    666 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    13 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →

    Hi all – we could really use more information on the use cases you would like us to deliver with this feature. To quote Darrel’s post below:

    Are you looking for some kind of UI in the portal to enable developers to subscribe to webhooks exposed by APIs?
    Or are you looking for the additional security provided API Management to limit what events a user can subscribe to?
    Do you want to correlate the API Management subscription ID with registered webhooks?
    Any information you can give about the scenarios you would like help with would be great.

    Many thanks

  3. OData Import

    Support import of API definitions and metadata from OData $metadata.

    240 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    13 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  4. Mark api/operations as obsolete/deprecated

    Our api is updating frequently. Some operations and even whole api could be deprecated.
    We can't mark api/operations as deprecated. Now, only modify description could help us but it's not enough. Because nobody really read the description from start to end. And we can't highlight information in it.
    Please- give as a button "Mark api/operation as deprecated" + textbox for description why it happened and what other method should be used now(maybe with checking that new operations is available).
    Also highlight information about api/operation is deprecated in a description or somewhere else for a current consumers.
    And in the final-…

    195 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  5. Do not deploy echo-api when deploying via the SDK or ARM template.

    If I create a new Microsoft.ApiManagement/service resource and I do not have any Microsoft.ApiManagement/service/apis defined I would not expect a "example api" to be included.

    The SDK and ARM templates are for people to automate their deployments, adding a API to show someone how to use the APIM service on ALL new deployments does not make sense in a scripted environment.

    If when creating a new APIM from the web portal causes it to add a extra api to show the usage of APIM, that is fine, I world totally understand that behavior. But adding un-asked for apis during a…

    90 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  2 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  6. Import mandatory query parameters as query rather than in the URL template

    When an API is imported into API-M using Swagger, mandatory query parameters are imported into the URL template rather than as query parameters.

    The effect of this is when a parameter is missing API-M returns a 404. The correct behaviour should be to return a 400 Bad Request with a validation error, or pass the request to the back-end API to return an appropriate error.

    I suggest adding an option to import mandatory query parameters from Swagger as query parameters.

    72 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  3 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  7. SOAP import WSDL with external XSD

    All our SOAP services files use external XSD files that are imported into the WSDL. To import these in API Management, we need to merge the files into one big WSDL.

    It would be nice if we could import the WSDL and the imported XSD files without the need to create a "merged" WSDL

    49 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  5 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  8. different endpoint for an operation based on product

    Would be nice to have the option to define a different endpoint to different products. This will allow to define a 'test' and 'live' products that works with different environments. While at the same time the developers keys, examples, etc are all in one place.

    46 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  1 comment  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  9. Multiple URL Template for a operation

    Having multiple URL Templates for a operation will make it easy to configure the optional parameters.

    45 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  10. Improved mutual certificate authentication for front-end / public endpoint

    The current method of verifying client certificates is by hard-coding the certificate thumbprint into a conditional in the policy.

    A better solution would be to be able to match the incoming thumbprint to ALL thumbprints in the uploaded SSL key stores. As described in the last paragraph here:
    https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-mutual-certificates-for-clients

    However, currently only the private certificates are exposed in the context variable (context.Deployment.Certificates) rendering the aforementioned code non-working.

    41 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  1 comment  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  11. Allow same API URL suffix across different APIs and API products

    We are facing the problem that we have multiple microservices developed by multiple teams which have independent delivery pipelines to publish their APIs.

    Dependent on the service functionality certain APIs shall only be usable/visible for specific uder groups. Hence, we have to publish them in different API products.

    In general, we want to design the overall API surface across API products in a REST-ful way with a consistent terminology.

    Currently this is not possible because we are facing conflicts between APIs and API products when the REST-ful notion would suggest functionality to be exposed under the same API URL suffix…

    39 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  12. Import and append api's to an existing api through arm deployments

    In the azure portal it is possible to append multiple backends behind one logical api endpoint. I want to have the same functionality via ARM. Every repo uses the apim devops resource kit to get the swashbuckle generated openapi spec and generates based on this the ARM that registers the API in APIM. Currenlty when you have 2 ARM templates that target an api with the same ID this api is replaced. It should be possible to append and postfix the operations in case of conflicts. So basically the same as the azure portal does but this time via arm…

    32 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  13. Allow longer URLs and Query parameters

    Currently URLs in the Consumption Tier are limited to a length of 4096 bytes with a maximum length for query parameters of 2048 bytes (source: https://github.com/MicrosoftDocs/azure-docs/blob/master/includes/api-management-service-limits.md). As there is no maximum size defined in the URL standard, the API Management shouldn't constrain the length of URLs and Query Params either (or should have a much higher limit which does not restrict realistic use cases). This would e.g. allow the transmission of data-URLs, Authentication information in the Query Parameter or signed URLs.

    30 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  14. Hiding operations in developer portal

    This is a duplicate but the original suggestion was closed as Completed.

    I would like to hide operations in the developer portal but still expose them through the proxy.

    29 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    6 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  15. Allow to filter/select operations when adding a new API from a OpenAPI spec

    Currently, if you need to create/update an API from an OpenAPI spec with only a small subset of the whole list of operations supported by your backend, you will need to edit the generated spec to remove all the operations/types not required which is boring and error prone, or import all of them and remove all the undesired ones one-by-one, which makes our lives sad and miserable..
    A simple UI which allows to filter/select the specific operations we need to import/update would be awesome!!

    28 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  16. Customize error schema messages

    Is there a way to control message error schema in Azure APIM? .. we don't want expose two kind of message errors .. we would like to return always the same structure.

    In our case, we use a diagnostics object to return message errors in our internal API:

    {"$diagnosis": [{"$severity": "error","$sdataCode":"errorCode","$message": "errorMessage","$source": "urlSource"}]}

    However, if we overflow the rate limit policy, Azure APIM returns an object like this:

    {"statusCode": 429,"message": "Rate limit is exceeded. Try again in 52 seconds."}

    We would like to return in this case something like this:

    {"$diagnosis": [{"$severity": "error","$sdataCode":"429","$message": "Rate limit is exceeded. Try again in…

    25 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    1 comment  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  17. Disallow or show warning when filling in duplicate OperationId

    When adding a new operation in Azure Api Management, you can type in the "name". In the backend this is the operationId.
    However if you type in an already exisiting operationId it will overwrite that operation (and merge certain features, like tags).
    It would be nice to disallow this, or to show a warning that this will overwrite an existing operation.

    25 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  18. Consumption Plan DevOps

    Currently consumption plan services are not discoverable via resource explorer this will impact the ability to automate the deployment of apis between API Management instances

    This is important if the consumption plan is to be used a lead into higher level SKUs especially as there is no upgrade option from consumption to higher level skus.

    20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  19. Importing swagger into API Management modifies the original swagger content...

    When importing the swagger document for an API the import process modifies the content which when output drives warnings in a swagger editor. Some items that appear to change, summary attribute becomes description attribute, consumes is dropped, a response type Object with type of array is redefined as a $ref and rename ObjectArray. It would be good to have the option to maintain the original definition and structure rather than modifying

    20 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  1 comment  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
  20. Basic Support for WS-Addressing

    The current support for SOAP-based services is good enough for some scenarios. However, one that I see missing that would make integrating WCF-based services easier would be to support basic WS-Addressing.

    In particular, if the API is implemented in WCF using WSHttpBinding with only transport security, it will be exactly the same as a regular BasicHttpBinding-based service with SOAP 1.2, except it will also require the WS-Addressing <To> and <Action> headers.

    For now, we've managed to make it work in SOAP-to-REST scenarios by manually inserting the WS-Addressing headers into the set-body template, but this can be very annoying for complex…

    18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Microsoft
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  0 comments  ·  Defining APIs  ·  Flag idea as inappropriate…  ·  Admin →
← Previous 1 3 4
  • Don't see your idea?

Feedback and Knowledge Base