This document provides steps to create a REST API proxy for an existing SOAP web service using MuleSoft Anypoint Platform and RAML (RESTful API Modeling Language). It involves designing the REST API interface using RAML, exporting the RAML file and importing it into a Mule project. The REST flows are then configured to call the underlying SOAP service using a Web Service Consumer and Transform Message components to map requests and responses between REST and SOAP. The end result is a REST API that provides access to an existing backend SOAP service.

1. HowTo – REST API proxy to
SOAP webservice

2. • This blog post is a continuation of our first How To series, “APIFy your
integrations,” where we started off by creating a SOAP API around a
database.
• Some organizations are entirely invested in either SOAP or RESTful
web services. There is plenty of material already written on SOAP vs.
REST, so there’s no need for us to take that on here.

3. • It can be a use case driven decision where SOAP and REST can co-
exist. With this approach, it is a common scenario to have a hybrid
environment where some system APIs exist as SOAP based web
services that need to have a REST interface defined.
• In this blog, we will walk through creating such a REST API proxy on
top of an existing SOAP web service.

4. • To get the best fit for our REST API, we will adopt a design first
approach. Before we touch a line of code to build the API, consider
what value our API needs to offer its consumers and exactly how they
will need to consume it. Allow time to get this interface right. Iterate
on the design, mock the implementation to enable consumer
interaction, and in parallel ensure it’ll be deliverable by your
implementers.

5. We will make use of an API description
language called RAML that:
• 1) provides a blueprint to design APIs from the top down with your team before
you decide on an implementation or begin to code.
• 2) acts as a contract by which we communicate with the API
consumers/partners/developers what this API will do and decouple them from
implementation.
• 3) acts as the metadata that facilitates system-to-system and machine-to-
machine interactions as well as a place to describe human readable descriptions
about the API.
• 4) provides tooling and specification that is very simple and clean for API
stakeholders to use.

6. System prerequisites:
• MuleSoft Anypoint Studio.
• API Designer.
• An existing SOAP web service. (refer to part 1 of this series to
create and deploy a SOAP web service using Anypoint platform). The
project for part 1 is downloadable here).

7. Steps:
• If there is no existing SOAP web service to proxy to, check part 1 of this
series.
• Sign up for an Anypoint account. Log into Anypoint Management Console
and create a new API.
• Open API Designer in the API detail page.
• Anypoint_Platform_for_APIs___API_administration___loanRestAPI_-_1_0
• Create a RAML file and document the interface as desired for the REST API
• http://raml.org/
• (Note: If you are using the sample web service from part 1 of this series
then refer to the RAML file in attached project).

8. • Export the api.raml file.
• Open Anypoint Studio and create a new project. Check “Add APIkit
components” and select the RAML file created in step 4. Click Finish.
• New_Mule_Project_and_Mule_Design_-_Anypoint_Studio_-
__Users_neerav_agrawal_Mule_Workspace_MuleWorkspace_Workspace_
API_Integration_and_Downloads
• When you create a new APIkit project and click Finish, Anypoint Studio
uses the imported RAML file to generate skeletal backend flows, one for
each resource-action pairing in the RAML file. Furthermore, Studio pre-
populates each of the flows with one or more message processors that
perform “mock” activities based on the content of the example response
included with each resource-action pairing in the RAML file.

9. • Delete the “Set Payload” activity from the flow “get:/loan:api-config.”
• Add a “Web Service Consumer” connector to the flow “get:/loan:api-
config”. Click on connector configuration.
• In Connector configuration add the WSDL location for the SOAP web
service. If the WSDL path is correctly configured it will automatically
populate the remaining fields. Click Ok. (Note: Enter the WSDL URL of
the web service you want to proxy to).

10. • Global_Element_Properties
• Add a “Transform Message” component to the flow. Here we will
configure the request message for the SOAP web service. Add the
input parameters. In this case, we extract the value from the HTTP
query param and assign it to the SOAP request(Note: Make sure the
namespace is configured correctly as per the target web service
requirement).

11. • We just implemented a REST API interface to a back-end service. We
can import this project as an Anypoint Studio generated Deployable
Archive and deploy it to a mule runtime on-premise or cloud.
• This blog is a follow-up to part 1 of the series “Create APIs on top of
an integration”.

12. To create a REST API we leveraged the following
features of Anypoint Platform:
• Adopted a design-first approach and use Mulesoft’s Anypoint
Platform for APIs to get one unified user experience across the API
lifecycle to streamline the creation, management and consumption of
APIs.
• Utilized RAML, which is the first standard facilitating the design-first
approach to APIs.
• Web-service consumer along with DataWeave & DataSense to help
consume the SOAP web-service with very less effort.
• Out of the box platform capabilities like auto-generation of
implementation and mock service that are available in the platform
that helps to design an API.