In this article, we look at how MuleSoft Anypoint and Azure Integration support building new APIs. Let’s have a look at some notable differences.
MuleSoft
In the MuleSoft methodology, the design of the API is the recommended starting point (design-first approach). The API Designer supports writing the API specification (in RAML or OAS format). During the design phase, it can be verified with business analysts and testers through either the mocking service feature or the web-based Flow Designer for quick logic building.
In developing the actual flows with the Studio IDE, the developer starts with the API specification, and can generate a skeleton for the Mule app based on this specification (‘APIKit’), thus automating this part of the development and ensuring the runtime app matches the specification.
API specifications, API fragments, connectors, templates, and examples can be published to the Exchange, so that architects, designers, and developers can find relevant information on the assets already developed in the organization. Exchange is the central place for internal stakeholders, while a separate Developer Portal can optionally be created when the API is to be consumed outside of the organization. The API Community Manager takes the API consumer experience a step further by adding more ways to interact (chat, forums, support case management) as well as more analytics.
In API Manager, the API developer imports the API specification and further configures runtime behavior like policies and alerts. Changes to the API operations must be done through a change of the API specification.
The library (Catalyst) has extensive guidance on shaping an API strategy that encourages teams to reuse assets. For example, it prescribes a 3 layer architecture model to structure the Integration landscape. A System API layer is suggested to abstract away the connectivity (e.g. authentication) and data model details of the backend systems, thus avoiding repetitive work and ensuring consistency.
Azure
In Azure, a new API is registered in API Manager based on an existing (OAS or WSDL) definition, or by starting from scratch and defining the API in API Manager. The API can be updated directly in the API Manager, including updates to operations. A mocking service is also included to simulate the API before a real implementation has been built.
It is not possible to generate a Logic App skeleton based on the API specification. The Logic App implementation is an autonomous flow with its own definition of the request and response message types. For the other way around there is an option to create an API (in API Manager) based on a Logic App.
In Azure, the Developer Portal is the place where internal and external developers can find APIs. For interacting with backend systems, invocations are made directly from the Logic App. Hence for multiple integrations calling the same backend system, this will lead to duplication of configuration and logic. It is possible to develop ‘custom connectors’ based on custom coding.
Conclusion
Design and creation of APIs is well supported by MuleSoft through the API Designer component. Azure does not feature an API design component and is expecting an existing API specification (created or generated elsewhere), or to have the developer build an API from scratch. This pragmatic approach is fine for prototyping situations (quick experimentation), but less suited when standardizing on certain aspects of the API like data model or security provisions.
For API implementation, there are two main options in Azure: a code-based approach through Azure Functions, or the lowcode approach in Logic Apps. Synchronous APIs were not originally suitable for building in Logic Apps, but with the recent enhancements, this is now a valid implementation option. However, the API implementation is still spread out over two distinct Azure services (API Management and Logic Apps), making API development more complex. MuleSoft by comparison provides an integrated way to develop an API: the workflow is not developed in isolation but is linked to the API specification.
Devoteam can help you evaluate Integration products based on the requirements that are important to your organization. Any questions or would you like to receive more information about our Integration & API services? Don’t hesitate and reach out to us.
Devoteam’s Integration consulting services
Building on 20+ years of extensive Integration experience at both multinationals and SMEs, we support our customers with Integration technology services. Our experts cover the full spectrum of skills, experiences, and proven approaches needed for the Integration of processes regarding customers, services, products, and operating models. In short, we enable seamless ecosystem connectivity for your entire value chain. We enable organizations to easily connect with their prospects, customers, suppliers & partners by:
- Setting up (hybrid) Integration platforms, from architecture to configuration
- Taking care of your Integration environment through a managed services model with different support levels
- APIs & API Management
- Electronic Data Interchange (EDI)