Publishing and Consuming APIs with Mule

Mule uses the CXF framework to provide support for publishing SOAP APIs, implementing Apache CXF . Apache CXF is a flexible, open-source services framework that helps you build Web services using front-end programming APIs, like JAX-WS.

You can use CXF in a Mule application to expose a SOAP web service using one of three ways:

Consume any SOAP API using the Web Service Consumer. This Anypoint Connector offers functions for consuming Web services within your Mule applications. Using the information contained in the API’s WSDL, the connector enables you to configure a few details to establish the connection for consuming a service from within your Mule application. First, identify the location of the Web service’s WSDL file, then ask the Web Service Consumer to configure itself from the WSDL – host, port, address.

Perhaps a connector has already been developed for the API you want to connect to. If so, look for it in Anypoint Exchange and download it into Studio.

APIkit, a tooling module that you can add to your instance of Anypoint Studio, is an open-source, declarative toolkit specially created to facilitate API-first REST API implementation. APIkit enforces good API implementation practices and streamlines API development by automating flow creation and providing an embedded console for quick testing and iteration.

APIkit for SOAP facilitates implementing a SOAP interface that enables external users to access your data, then integrate it with backend processes to function as an API.

APIkit can create an API based on a RAML (RESTful API Modeling Language) API definition, as described in the APIkit tutorial. APIkit produces a Mule application with an HTTP endpoint, exception strategies, and hooks for your backend. Further, it offers an API console that exposes auto-generated, fully testable documentation for your API.

To consume a REST API using Mule, use one of the following techniques:

To use an HTTP connector, you configure MEL expressions to pass the necessary information to your API. If a RAML file exists that describes the API you want to consume, you can reference it in the HTTP Connector to expose the structure of the API at design time. This action saves you from having to research what to include in requests and what responses to expect. If you don’t have a RAML file for your API, be aware of the structure of the API you want to call, including any authentication requirements, the names of one or more resources to access, and the methods supported for each resource.

You might want to consider writing a RAML file for this API if one doesn’t exist and you plan to consume it repeatedly. Building your own connector instead of configuring HTTP endpoints makes sense if you plan to frequently consume the API or if you need security beyond HTTPS or basic authentication.