Mule ESB vs WSO2 API Manager

• It is best suited for Rest API development. Mule ESB uses RAML as an API descriptor which is less complex and easy to understand. RAML is an open standard majorly supported by Mulesoft. Once RAML is developed, it is very easy (a few clicks)to create flows corresponding to the resources defined in the RAML. One can also include JSON schema validation in RAML, and with the use of APIkit router, Mule ESB makes the request validation very easy (it's automatic basically.)
• Mule ESB comes with a large spectrum of community and enterprise connectors. We have connectors for all the major platforms like Facebook, Twitter, Salesforce, SAP, etc. This enables Mule ESB to integrate with the other systems in a faster and more robust way. Mule ESB has many components to fulfill the requirements of each integration (for example batch processing, parallel processing, choice, etc.)
• Mule API gateway is one of the best tools (modules) of Mulesoft's offering. It supports API governance and management very well. One can easily enforce policies on their APIs with API gateway. It enables some of the must-have features in an API solution (i.e. throttling, oAuth, access levels, etc.)
• Implementing a CI/CD (DevOps) environment for Mule ESB is a very easy task. Mule majorly uses MAVEN as its build tool, which in turn makes it best suitable for CI/CD approach. Mule also provides MAVEN plugins for auto deployments to the servers. Mule also has a best Unit testing module which is MUnit. MUnit can be used for both Unit and Functional testing, and it is easy to write and generates coverage reports in various formats.

Read full review

• Nice API store-front capability
• Management of users and permissions

Read full review

• Make sure to not over-engineer shared components. It can complicate development
• Create a roadmap for where you are going - if not, you may miss components
• I suggest getting support, otherwise it could be a difficult learning curve

Read full review

• Installation of this product is a hell. You need to be an expert to get this running together with WSO2 Analytics. It uses a really confusing method of "port + 1" to connect extra products. I guess this was meant to provide a handy way to add new WSO2 products. In reality you'll need to scroll through numerous config files to set this straight. If you use this out of the box, everything will work all right. But the moment you add SSL certificates, DNS names and you'll need special ports to configure your firewall, this product becomes unmaintainable.
• The "Store" provides a nice way to group API's. However, the "Publisher" does not... if you have more than 30 API's searching for API's becomes really annoying.
• The number of configs in this product is huge. As a developer myself, I've never seen (and definitely never created) a product that needed that much config files. Installation and maintenance of products should be stupidly simple, since no developer nor infrastructure person wants to learn something that "just" needs to be a tool.. opposed to being a whole new area of expertise. After using WSO2 API Manager for a while, we wanted to change the admin password... this should be simple enough, like just change the password in "Carbon." But nope. The whole WSO2 environment crashed. We just gave up. Too dangerous.
• Why so many different "products"? Publisher, Store, Carbon, and numerous hidden interfaces. Analytics, ESB whatever... No wonder there are so many config files and port issues. Make it simple!!!

Read full review

• Overall a great tool for complex integrations

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