Generate REST APIs from SOAP Backends

This feature allows users to expose their legacy SOAP backends as REST APIs through WSO2 API Manager. WSO2 API Manager supports WSDL 1.1 based SOAP backends.

The following instructions explain how to generate REST APIs in WSO2 API Manager for an existing SOAP backend.

Before you begin...

Make sure that you have a valid WSDL URL from the SOAP backend. It should belong to the WSDL 1.1 version.

Sign in to the API Publisher and click ADD NEW API, which is under the API menu.
Select I Have a SOAP Endpoint. You see the following two options to create APIs for SOAP backend.
- Pass Through – Create a pass through proxy for SOAP requests coming to the API Gateway. You can either select a WSDL URL to provide a URL for your API or you can upload a WSDL archive/file.
- Generate REST APIs – This option is used to generate REST API definitions from the given WSDL URL. Therefore, select a WSDL URL to provide a URL for your API.
Select Generate REST APIs (The default option is Pass Through). Provide the WSDL URL given below for the SOAP backend and click Start Creating.
Sample WSDL URL
```
http://ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl
```
The WSDL URL and WSDL Archive/File options that are shown in the following screenshot, which allow you to modify API resources, are only available as a WUM update and is effective from 11th January 2019 (11-01-2019). For more information, see Updating WSO2 API Manager.
Click on Edit Source to edit the Swagger specification of the API.

When generating the API using WSDL, POST resources only get generated with the request body and the API does not get generated with the query parameters. If you are using the WUM update and if you need to add query parameters to a POST resource, you need to modify the Swagger definition of the API.

The automatically generated REST resources of the API appears.
You can describe your REST API better by modifying the Open API Specification that you see on this page. The following is a sample of how this particular API has been described.

Optionally, update the Swagger definition of your API and click Apply Changes to save your API.
Let's update the API by replacing the existing Swagger definition with the following Swagger definition.

Expand to see the edited Swagger definition...

swagger: "2.0"
paths:
  /checkPhoneNumber:
    get:
      operationId: CheckPhoneNumber
      parameters:
        - in: query
          name: PhoneNumber
          required: true
          type: string
        - in: query
          name: LicenceKey
          required: true
          type: string
      responses:
        default:
          description: ""
          schema:
            $ref: "#/definitions/checkPhoneNumberOutput"
      x-wso2-soap:
        soap-action: "http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber"
        soap-operation: CheckPhoneNumber
        namespace: "http://ws.cdyne.com/PhoneVerify/query"
        x-soap-version: "1.2"
  /checkPhoneNumbers:
    post:
      operationId: CheckPhoneNumbers
      parameters:
        - in: body
          name: Payload
          required: true
          schema:
            $ref: "#/definitions/checkPhoneNumbersInput"
      responses:
        default:
          description: ""
          schema:
            $ref: "#/definitions/checkPhoneNumbersOutput"
      x-wso2-soap:
        soap-action: "http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumbers"
        soap-operation: CheckPhoneNumbers
        namespace: "http://ws.cdyne.com/PhoneVerify/query"
        x-soap-version: "1.2"
info:
  title: PhoneVerificationAPI
  version: 1.0.0
definitions:
  checkPhoneNumberInput:
    type: object
    properties:
      CheckPhoneNumber:
        $ref: "#/definitions/CheckPhoneNumber"
  checkPhoneNumberOutput:
    type: object
    properties:
      CheckPhoneNumberResponse:
        $ref: "#/definitions/CheckPhoneNumberResponse"
  checkPhoneNumbersInput:
    type: object
    properties:
      CheckPhoneNumbers:
        $ref: "#/definitions/CheckPhoneNumbers"
  checkPhoneNumbersOutput:
    type: object
    properties:
      CheckPhoneNumbersResponse:
        $ref: "#/definitions/CheckPhoneNumbersResponse"
  StringArray:
    type: string
    properties:
      String:
        type: array
        items:
          type: string
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  CheckPhoneNumber:
    type: object
    properties:
      PhoneNumber:
        type: string
      LicenseKey:
        type: string
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  CheckPhoneNumbersResponse:
    type: object
    properties:
      CheckPhoneNumbersResult:
        $ref: "#/definitions/ArrayOfPhoneReturn"
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  ArrayOfString:
    type: object
    properties:
      string:
        type: array
        items:
          type: string
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  ArrayOfPhoneReturn:
    type: object
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  CheckPhoneNumbers:
    type: object
    properties:
      PhoneNumbers:
        $ref: "#/definitions/ArrayOfString"
      LicenseKey:
        type: string
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  PhoneReturn:
    type: object
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s
  CheckPhoneNumberResponse:
    type: object
    properties:
      CheckPhoneNumberResult:
        $ref: "#/definitions/PhoneReturn"
    xml:
      namespace: "http://www.w3.org/2001/XMLSchema"
      prefix: s

The generated API definitions are added to the API as shown below.
A REST API method is mapped with the corresponding SOAP operation through a Swagger, vendor-specific field - x-wso2-soap. Note that this should not be edited. A parameter without this field cannot be mapped with a SOAP backend operation.
See the sample REST operation given below.
/checkPhoneNumber: post: operationId: CheckPhoneNumber parameters: ... x-wso2-soap: soap-action: "http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber" soap-operation: CheckPhoneNumber namespace: "http://ws.cdyne.com/PhoneVerify/query" x-soap-version: "1.2"
The operationId parameter is used to map the REST resource with the corresponding SOAP operation.
Edit the details of the API as shown below.

Field Sample value
Name PhoneVerification
Context
/phoneverify
Version 1.0.0
Access Control All
Visibility on Store Public
Tags
phone
For more information on the meanings of the latter mentioned fields, see Create and Publish an API.
Go to the Implement tab. Click on Managed API.
Select the Endpoint Type as the HTTP/SOAP Endpoint. Enter the SOAP endpoint URL given below.
SOAP Endpoint URL
```
http://ws.cdyne.com/phoneverify/phoneverify.asmx
```

Navigate to the SOAP to REST Mapping section. Click on a resource to view the In and Out sequences of the API.

The following is a sample Synapse based XML configuration which reads some parameters from the request path and constructs the SOAP payload required for the backend (target) services.

<header description="SOAPAction" name="SOAPAction" scope="transport" value="http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber"/>
<property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
<property expression="$url:PhoneNumber" name="req.var.PhoneNumber"/>
<property expression="$url:LicenceKey" name="req.var.LicenceKey"/>


<payloadFactory description="transform" media-type="xml">
  <format>
  <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:web="http://ws.cdyne.com/PhoneVerify/query">
  <soapenv:Header/>
  <soapenv:Body>
  	<web:CheckPhoneNumber xmlns:web="http://ws.cdyne.com/PhoneVerify/query">
   <web:PhoneNumber>$1</web:PhoneNumber>
   <web:LicenceKey>$2</web:LicenceKey>
</web:CheckPhoneNumber>

  </soapenv:Body>
  </soapenv:Envelope>
  </format>
  <args>
 	<arg evaluator="xml" expression="get-property('req.var.PhoneNumber')"/>
<arg evaluator="xml" expression="get-property('req.var.LicenceKey')"/>

  </args>
</payloadFactory>
<property description="messageProperty" name="messageType" scope="axis2" type="STRING" value="application/soap+xml"/>

The incoming JSON message parameters are stored using properties. The SOAP payload needed for the backend is generated using a payload factory mediator.

Go to the Manage tab and select the throttling tiers for the API. Click Publish to publish the API to the API Store.
For instructions, see Create and Publish an API.
Navigate to the API Store and subscribe to an API.
After generating the production and sandbox keys you receive a valid access token to access the API.
https://localhost:9443/store
Run the following HTTP request to invoke the API.
You receive the actual backend response.
Related Links
- Create and Publish a SOAP API.
- You can also invoke this API using a third-party tool such as SOAP UI. For more information on how to invoke an API using a SOAP client, see Invoke an API using a SOAP Client.

Field		Sample value
Name		PhoneVerification
Context		`/phoneverify`
Version		1.0.0
Access Control		All
Visibility on Store		Public
Tags		phone