Publishing and Consuming APIs with Mule
|Mule Runtime Engine versions 3.5, 3.6, and 3.7 reached End of Life on or before January 25, 2020. For more information, contact your Customer Success Manager to determine how you can migrate to the latest Mule version.|
Using Mule applications, you can both publish and consume APIs. Depending on whether you are using REST or SOAP, and whether you are exposing or consuming the API, Mule offers different tools to facilitate your use case. Select from the matrix below to read more about the options Mule offers for each goal.
|Rather than using both "API" and "Web service" to refer to the code written to interface with other code, this documentation only uses the term API. While these terms are, technically, not interchangeable in every circumstance, for the purpose of consistency and clarity, this Mule documentation simply uses the term "API".|
You are reading this document because you want to either publish or consume a Web service or API using Mule. This document assumes you are reasonably well-versed in both REST and SOAP architectural styles for APIs. This document also assumes that you are familiar with Mule ESB and are comfortable building applications with Mule. Read the Mule Fundamentals to gain familiarity 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:
Use the proxy service pattern to build a WSDL-first API
Use the JAX-WS service pattern to build a code-first API employing the standard JAX-WS annotations with JAXB databinding
Use the simple service pattern in the SOAP component to generate an API from POJOs
Learn more about Publishing a SOAP API with CXF
Consume any SOAP API using the Web Service Consumer . This new Anypoint Connector offers a streamlined set of functionality for consuming Web services within your Mule applications. Using the information contained in the API’s WSDL, this connector enables you to configure a few details in order to establish the connection you need to consume 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.
|Consider that perhaps a connector has already been developed for the API you wish 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 accepts a RAML (RESTful API Modeling Language) API definition and 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.
There are two approaches to consuming a REST API using Mule:
Configure an HTTP connector to send requests to, and accept responses from an API from within your Mule application
Build a connector using Anypoint Connector DevKit to perform operations against the API
The lightweight option is to use an HTTP connector configured with MEL expressions to pass the necessary information to your API. If a RAML file exists that describes the API you want to consume, then you can simply reference it in the HTTP Connector and it will expose the structure of the API to you at design time, saving you from having to look up reference material to know what you need to include in your requests and what these return. Note that, if you don’t have a RAML file for your API, you need to be aware of the structure of the API you want to call, including any authentication requirements, the name of the resource(s) you want to access, and the methods that are supported for each resource.
You may want to consider writing a RAML file for this API if one doesn’t exist and you plan to consume it repeatedly.
You may want to consider building a connector for the API instead of configuring HTTP endpoints if:
You will be consuming this API very frequently, and you don’t want to have to configure your connection via HTTP each time that you want to connect
You need to connect to a REST API secured by any authorization standard that is more complex than HTTPS or basic authentication
If either or both of these describes your use case, visit the DevKit documentation to learn more about the process of building a connector.