Support for GraphQL could be better. We work with different standards, but at the moment, it only supports GraphQL as a specification. However, support for GraphQL, which is a different communication specification, needs to improve.

An area for improvement in Microsoft Azure API Management is deployment, in particular, the deployment of versions in Oryx. The development to production instance isn't adequate for me and needs to be improved.

To explain further, the specification for the API needs to be deployed from development to production through scripts, and the scripts need to be done manually or need a lot of manual intervention. The process isn't automatic or click-and-point, so you need a technician. 

Microsoft Azure API Management lacks automation, which is another area for improvement.

In the next  Microsoft Azure API Management release, I want to see the automatic deployment of its versions.

Price is the first thing that comes to mind. It's quite expensive, which could be a barrier for some users.

So, pricing is an area of improvement. 

It is a good solution. The latest versions of Azure API Management have included many new features. At the moment, our APIs don't follow the RESTful concepts. So, we face a challenge at the initial stage of the project. We need to get cache policy requests. We have to develop rules internally for cache requests with the policy methods. So many other companies must be needing this feature. They should work on it in Azure API Management's following versions. 

Specific to API development, I think Microsoft is still far behind AWS. AWS has grown by leaps and bounds, and Microsoft is a close second. But in terms of features and other stuff they provide, Microsoft's compatibility with publicly available APIs is a little limited. So, that is a little bit of a constraint. But what they provide is good, it's just that they need to build more on their API suite. I think Google is doing a really good job at that.

There is room for improvement in the user interface and workflow for hosting APIs, especially third-party APIs. 

Another area of improvement is the pricing model. The solution has an add-on cost, and if we want to leverage some of the features, we are forced to buy it. So, cost-wise, it's not ideal.

We have to put the logs in Datadog. We need to use some other product to do all of the things we want. That costs extra. However, there are other solutions, like Dynatrace, that offer more features and have more functionalities. Right now, we have to use logic apps. You need more third-party apps to fill in the gaps. 

If I want to connect to other apps to Saleforce or Snowflake, et cetera, I need a quicker way to do mapping and to integrate everything together. 

I need to have microservice access. 

I'd like to have better flexibility and more capabilities. 

I would like to see more security features become available. For example, the integration on premises could be better. Things could be more user-friendly. Currently, the integration we work with is more complex than it needs to be.

It's okay. It's not as good as Google. For instance, in Apigee, in Google.

One of the most important improvements for us would be if it supported the HTTP/3 version and new protocol over a quick connection. It's a relatively new standard since 2020. 

There is a limitation of 32 kb of data in the APIs. Having the limitation increase would be a benefit.

The hybrid part could be improved because API Management is entirely cloud-based, but some of our resources are on-prem, so formatting is an issue. Our goal is dual implementation. 

There's always room for improvement in terms of the user interface. Generally speaking, technology evolves, so any service provider needs to make their product as user-friendly as possible. In the next couple of years, we'll see more non-tech people handling tech solutions. The solution should be more accessible, so people can use it to create things without being very tech-savvy.

The solution isn't missing anything. For the use case that we have right now, it's perfect. It offers everything that you'd look for in an API Management solution.

There's a new developer portal that's been added before they rolled out the new updates. I haven't really checked it out, however, the developer portal that they introduced is better than before. They've really improved on that one. If you are using the old portal, it's not as good. 

We have two different customers. The other customer wants us to move completely, to migrate their APIs to Azure. The other one wants to manage their APIs, which are running on-prem. I've explored that in the flexibility, in terms of integration with an on-prem environment. The integration could be improved for those on-prem use cases. 

The integration with other API gateways is where they might try to improve.

Support could be better. 

The API gateway can be very complex. We had difficulty managing end users for a very, very complex project. 

I am not sure that another API gateway would have better handled this difficult project. 

They need to work on the third party integrations. 

I'm not sure if there are certain areas needed for improvement. I haven't explored its shortcomings. So far, the requirements have been met.

Maybe the customization could be a bit better. 

My team found difficulty in migrating APIs from one platform to this platform. We could export and import properly. We made a complete API for a UAT environment, and when we moved the APIs, we ran into issues. 

They don't have a standard local IP. They only have a public IP.

API Management's price could be lower.

Pricing is definitely an aspect that can be improved. They should offer an additional free tier. For example, if there was a tier for new accounts created, it may help their services by getting people onboarded. Once you will give access to someone and they try it they'll see, "Okay, it works and you can pretty quickly add something on top of it". After that, the client will end up staying, and probably paying.

The cost is also complex in terms of calculating how much everything will ultimately be priced at. It's not straightforward as it takes into account multiple factors.

Technical support could be more flexible and try to meet the client's needs a bit more effectively.

The solution needs to provide more use cases so that we can refer them to clients. It will help answer any questions in relation to performance and load management.

Microsoft Azure API Management is lagging behind Apigee and should also have a better CICD process.

Other than the cost, it is difficult to customize. The external policies are impossible to look at and configure.

The deployment time is too long. It is difficult to have multiple authentication mechanisms and authorization mechanisms at the same time.

Microsoft Azure API Management has not improved since I last used it in 2017.

By using Azure you are forced to use their technologies. For example, I wanted to use PostgreSQL, but I could only use SQL server. I also wanted to use Java or TypeScript, but the only option is .NET, which we do not use. They are very difficult to collaborate with as the solution does not integrate with other products. 

They do not offer extensions, if you want to use a Swagger extension you have to use XMLs, which are very complicated.

Another concern is that Microsoft Azure often does not have enough Linux machines in the region. If you want to deploy on Linux, and there are not enough, they will tell you to deploy in another region, or it has to be on the Windows server instead.

It would be better if it were easier to transition to Azure from JIRA. For example, there are different nomenclature that must be addressed when you shift to Azure from JIRA. JIRA's storage, tasks, and epics are treated differently from Azure. 

Here they might become functions, which is not an option in JIRA because that nomenclature difference is there. 

JIRA has sub-tasks, but sub-tasks don't exist in Azure. The nomenclature and the linking between Epics and a function and a story are different, and people may have to learn to adapt to the new nomenclature.

In terms of the flexibility of API Management, it's quite a complex solution when compared with Apigee. If they could come up with an easy way of enhancing, that would be a great help, particularly for those consulting.

Microsoft Azure API Management's most valuable features are the microservices we used to use. They were API callers to receive communication with the network and building system, to complete the request. The response would be through the processing system.

Some of the DevOps stuff could be easier to work with. The migration paths are a little complicated, and moving code around could be more seamless. There should be less manual migration when several teams work together to publish code to the DevOps. 

For example, if you and I are working on the same application, and there are conflicts, you should be able to resolve those conflicts more easily. It shows you the conflicts, and you have to fix them yourself. Better conflict resolution with software migration is what I recommend.

It should be easier to integrate.

The solution’s security and performance could be improved.

The scalability of this solution could be improved. The volume which the API Management task service can handle needs to be improved. Cost wise, this solution could be optimized.

Nothing in specific but there is always some improvements that can be made to user interface to enhance and improve the UX experience. 

As Microsoft adds more an more services to the stack will help and enable to ease the API platform integration with other ERPs and various platforms for us. There are more APIs coming out with lot more enhanced services that include IOT connected device integrations. Any help in understanding available API protocols and edge protocols easier will help us building our solutions faster.  We do see different services are being added day by day.

We are not using all of services at this point, but we are leveraging few at a time and building our solutions.  This is part of the evolutionary and exploratory based journey to transform the ecosystem of the customer to a digitally connected growth organization.

I don't really have anything in mind at the moment in terms of areas of improvement. It does what we need it to do for the most part.

Technical support could be more helpful and responsive. They are quite slow. 

The documentation around the solution is lacking. Users will need to do a lot of digging and googling in order to get the answers they need. 

The premium version is very expensive. 

VNet integration facility is only available in the premium version so that is a drawback.

The lack of wording in the API could be improved. In the API you need to delete the suffix. It is annoying that you need to have a suffix. We can add a suffix at the API level, not at the operation level, and that could be improved on.

There are a couple of features that are lagging.

The implementation has room for improvement and can be more user-friendly.

We need better integration with VNet. 

It would be nice to not only configure it through the interface but also with an ARM template or something like that. Maybe it's possible, but it's not that easy to find.

It took us time to get used to the interface. Now that we run it, it's a little bit hard to have a testing environment and the production environment and keep it synced. If you can do that through a script, that would be far easier. However, there was a time thing on our side. We couldn't get it done, and in the end, we just set it up manually.

The licensing tiers can be misleading. 

It would be ideal if there was a way to add monetization into the mix so that we could more easily sell our APIs.

Azure API Management could be improved with better integration with all of Microsoft's tools. They should also provide basic cybersecurity tools in the package.

Microsoft Azure API Management needs to improve stability. 

When comparing the API Gateway of Microsoft Azure API Management with those of Apigee and Vital Mikram, which are other API management solutions, I prefer, Vital Mikram, the others are similar.

I would like to see more integration with other platforms, as well as increased security.

An improvement would be to provide more information about additional prices and the onboarding process.

If I compare this solution to others I have used in other phases of my life, having APIM being an Azure resource, it is easy to configure and deploy. However, this conversely reduced the flexibility. The difficulty is how do we configure it in a manner that a larger enterprise would probably want it to be. This creates a bit more complexity, working around the constraints of the resource itself. If comparing it to other solutions, it is more of a legacy design with an older approach. The various level components are still around resembling an on-premise type of design similar to other solutions, such as Apigee or Mulesoft. They are still predominantly carrying some legacy design. Which might be suited for organizations where they have a more complex network layout. APIM is easy to deploy, but on the other side of that, it is constrained to how Azure has designed it to be.

In an upcoming release, if not already added through an update, I think dynamic provisioning of the resource would be useful. Many times these API platforms, including others, such as Apigee, are still predominantly revolving around developers. The onboarding and the API life cycle are still revolving around humans. In this context, I would not suggest DevOps, but at least automation of common pipelines. If the platform can better support this in the workflow to provision and commission an API that would be beneficial as we work towards a more automated deployment concept. Even though there are templates, graphics, and API management commands right now, you are still in a way programmed deeply, customizing that workflow, as opposed to it being part of the platform itself.

There is always room for improvement. There should be more analytics abilities so you can know how much traffic there is. Log Analyzer isn't well integrated with this solution. 

Microsoft Azure API Management could improve the documentation. The documentation feels like marketing information and not sufficient technical information. Your easiest option is to purchase services from a Microsoft partner and this is their marketing.

In a feature release, there could be a better Canary release. They have a release but you need to code it yourself.

There's some area for improvement for this solution's performance. Sometimes it can be challenging. We're working with design patents and we're hoping to see the performance issues sorted out.

The only complication I encountered was configuring the authentication in the API Management. That was a little difficult for me, but it gets better after that.

I could that the UI could be improved. All services have the use of Visual Studio to do the coding and to change the configuration. It would be beneficial to include that with Microsoft Azure API Management.

What would make Microsoft Azure API Management better are more APIs. They keep updating their APIs, but it would be better if the solution had more APIs for the services and more integration with other platforms.

In the next release, Azure APIM should include deployment in various environments and CI/CD for deployment. They could also improve their access management portal.

One thing that could be improved is to remove the dependency of Kubernetes as an external L4 load layer balance. It would also be useful if APIM could integrate internally with Kubernetes right out of the box.

Microsoft Azure API Management should have the ability to allow multitenancy.

While the solution works well for us, I would like to see simple or integrated reporting built into the solution.

There is always room for improvement.

They're trying to implement versioning and trying to be able to manage different versions of your API all at the same time, but they're not doing that just quite right yet.

Other products offer more customization options. 

The API gateway, when it is deployed, is not as robust as Apigee.

I would like to see better scalability and better performance. Performance is important for us.

The developer console for external users could be improved, especially in the testing site. I would like to see the security management for the APIs to be more granular.

It could be more user friendly for developers. It would be nice if developers could view things more easily.

We haven't used API model that much, so I'm not in a good position to say recommendations as we are still exploring the Azure API management. We need more time to fully take in the solution before pointing our its flaws.

The documentation could be improved for the customer. The instructions on the district API and the initial stages of working with the solution need to be documented better so that users are more informed and they can have an improved experience.

The portal where we publish the APIs could be improved. Maybe this is because we didn't configure it. It is quite easy to bypass API management because we have a lot of information shared on the portal, where we publish our APIs. I worry there is potential for a security breach in the API publishing. There needs to be more security available on terms of the way we publish them.

The product needs to introduce a developer portal. 

The cloud deployment performance could be better.

Technical support could use some improvement.

Microsoft Azure API Management could improve by having better integration with third-party solutions.

In an upcoming release, there should be more focus on API lifecycle management, such as MuleSoft provides and the API gateway is not comprehensive enough, we need to put a lot of extra effort doing manual work. 

This solution is only available as a cloud-based deployment and it would be very helpful to have an on-premises version. This is driven by the fact that some of our clients have specific requirements and they do not want to be on the cloud.

I would like to have an administrator's option that shows me API usage and can generate bills that I can send to my customers. Currently, our customers can see the usage but not how much it is going to cost. For example, assume that you get 100 calls for free and then 100 more free each month, but after than, each call costs twenty cents or one cent, whatever the price is. The administrator can generate reports when the bills are available and can charge them to the customer. This could be done with a monetization module, which would be better than the manual calculations that we have to do now.

• An IaaS option is needed. The SaaS option limited our requirement, as we wanted more control on our data, and integration with our virtual LAN. Integration with our VLAN was possible only with the premium version and expensive gateway controllers.
• PCI compliance

The licensing fees should be cheaper.

From my understanding, there are some constraints around governance and service-to-service intercommunication managing priorities and our own governance. Examples include, how you manage all your clusters, the entire service communication, and having more tolerant experts.

They should improve the inbuilt policies that they have and that should properly create a deployment architecture as well.

Security could be improved.

• Versioning of API operations (which I have heard is in the pipeline)

• Easy exporting of configurations from the Administrator portal.

Multi-tenant functionalities is missing from the system, especially when it comes to purpose specific requirements such as CI, branding, language, content structure. If you're aware of the details of API Management provided by Azure, there are two areas. One is for developers, and the other is for consumers. In order to support the best, or all the different use cases we have, the multi-tenant support would be appreciated.

R&P, the publishing process could be improved. They are currently restructuring it, I believe.
I'm not technical but we noticed that the old developer portal got deprecated and they're introducing a new one. It's not polished and still requires some development. It's the same with the publisher portal which I believe they've now integrated into the Azure portal. They're just starting to work with hybrids so it still requires input. 

It would be helpful if they were to include additional features and clearer configuration when it comes to API policies.

The developer portal can be improved. There should be more resources available for the developers.

Better integration with third-party products would helpful.

In terms of improvement, it would be helpful if they could develop an on-premises option.