Likelihood to Recommend If you are truly using IBM API Management for an API gateway, you will be ok. if you start trying to build custom scripts to transform messages complex in nature, it will soon become unmanageable.
Read full review It's free! No argument can win a fight with that! And it's the only reason I gave it a 5. If you have no money to spend, and a simple environment you'll have a nice product. But free does come with a price. After 5 years we're still struggling with ports, and analytics (it just won't work without any errors caused by some configuration somewhere). An API Manager should work out of the box. The only configuration expertise that any developer wants to invest in, is the configuration of API's. Not the product itself... Anyone who've seen the training material, just for installing this thing will agree that this is not the way to go. Of all the API Managers out there (we've tried 4), WSO2 is the only one were you need to know how this dragon of a java application works internally. Did I already mention the humongous amount of config files?
Read full review Pros Import APIs - We have an existing inventory of APIs and services, so having an easy import process was required. IBM provides the ability to import Swagger so the process was quick and easy. Service Offerings - Can create plans to control various model offerings for varying clients depending on the need. You are not locked into a tier structure and can customize if a need arises. API Usage - visibility into the use of an API with a wealth of reporting information allows you to support an API from a production use to trending and forecasting any future growth. Read full review Authentication based on OAuth 2.0 and HTTP Basic Authentication. Rate Limiting applied at different levels like Subscriber, API, Resource and Backend. Monitoring by exporting the metrics in Prometheus and traces in Jaeger. Mediation to perform transformation, orchestration etc. Read full review Cons Troubleshooting deployment pipeline - identifying issues with your api based on restrictions through a deployment pipeline is difficult. If a quality assurance environment is less stringent than a production environment, making sure your api is accessible and configured appropriately is tough. Code level scripting is limited to javascript and xslt. so if any complex fanning needs to occur, you are limited in tooling. Administration is more cumbersome than it needs to be. There are roles/profiles that are defined, but to use a group email for the approval or use of an api needs to managed better. A more thorough thought process needs to be defined - which I think IBM is tackling as an improvement. Read full review Better QA testing prior to releases rollout Better support needed Read full review Alternatives Considered There are a lot of similarities between
Apigee Edge and IBM API Management. Some of the differences at the time of this posting is... 1) IBM APIM/C integrates better with other products. Dynatrace is used to track API and service specifics with the ability to offload those statistics for operational reporting. 2) If you are evolving from DataPower, IBM API Management is a logical choice to support additional REST APIs. 3) Generating keys is simple. Integration of those keys with a secure data vault is easy as well for your consumer.
Read full review Providing better capabilities comparing the overall API lifecycle management, especially the availability of API Integration layer and a strong identity layer of their own which provides an end-to-end API ecosystem that would be advantageous in terms of a large software development initiative.
Read full review Return on Investment Centralizing on an API management platform was imperative. Being able to support SOAP UIs as well as REST APIs was required. Because of the tooling, service inventory and provisioning can be managed - regardless of the pricing and cost structures are used. Constructing plans that provide tiering options based on rate limits help in onboarding new consumers. The lesser cost in onboarding through an API gateway outweighs the cost of modifying/configuring an API to handle multiple clients. Defining guidance and onboarding practices while rolling out the product also helps in the adoption, reference architecture, and governance that can save your company money. Read full review We've moved away from legacy SOAP services where nobody knew what services was used by who. WSO2 eliminated at least 90% of time spend on any service. Creating API's (or actually creating the API Management layer...) is so simple that new developers can get away with it in no time. Again, real time gainer. Since creating API's is so simple, developers are very fast in adopting a kind of "Domain thinking". In comparison with Azure API Manager: Azure does not demand knowledge of "how" the product works, but it's definitely more difficult to get an API up and running in Azure. And for some reason, azure does not promote clean domain driven architecture. Domain Driven architecture is the greatest time saver strategy possible. And WSO2 fits nicely in there. Read full review ScreenShots