Skip to main content
Options such as rewriting the existing service with REST or developing a new REST API that mimics its methods are not cost-effective solutions in terms of time and cost.
Apinizer enables exposing SOAP Web services as REST and performing all necessary transformations through configuration.

​
Creating REST Type API Proxy from SOAP Web Service

1

Upload WSDL File

When creating a new API Proxy, Enter URL or Upload File options for WSDL type are selected as appropriate. In this example, the Enter URL option is used.
2

Enable Protocol Transformation

After the URL is entered and the Parse button is pressed, in the Protocol Transformation section on the screen that appears, the REST to SOAP to REST option is marked.
3

Create API Proxy

Other required information is also filled in and the API Proxy is created.

​
Method Transformation Settings

After the API Proxy is created, if desired, how the transformation between REST - SOAP message structures will be done for request and response messages of methods can be customized.
1

Go to Development Tab

Go to the API Proxy’s Development tab.
2

Select Method List

When All is selected in the method list on the left, icons that open the transformation settings for request messages at the top and response messages at the bottom appear in the middle section.
3

Open Transformation Interface

When the icon for request messages is clicked, the protocol transformation interface opens. This interface has Request Options and Response Options tabs. The relevant tab opens depending on which icon the user clicked.
4

Configure Transformation Settings

In this interface, formatting is done regarding how the incoming request message will be converted to SOAP structure before being sent to the Backend API, in accordance with the REST protocol. The method whose message structure will be updated is selected from the left. The transformation settings for that method are made on the right.

​
Transformation Options

When a SOAP Service is exposed to clients as REST, request and response messages need to be transformed. The JSON message coming from the client must be converted to XML message before being sent to the SOAP service, and the XML message returned by the SOAP service must be converted to JSON message before being sent to the client.
There are various options for performing this transformation. Below, the features and usage areas of each option are explained.

Jackson Transformation

Preferred when the JSON message to be used in request and response messages needs to be simple and easy to understand. Highly customizable compared to others.
The most preferred method.

JsonML Transformation

Preferred when the JSON message to be used in request and response messages needs to include XML Attribute values and XML Namespaces.
JSON format is more complex compared to others. Data size increases because it resembles XML representation due to namespaces in the representation.

Template Message

Works on the logic of creating the XML template to be sent to the SOAP Service, regardless of what format the incoming JSON message is in. “Request/response data manipulation” is used to fill the parameters in the XML template.
Since there is no support for multiple sub-elements, it is useful when there are simple-structured XMLs.
Especially preferred when data is desired to be taken from request header or request parameter instead of JSON message.

​
Request Message Transformation Options

This section explains the details of transformation options for request messages.
Fields and descriptions available for Jackson Transformation:

Ignore NULL Values

Field: Ignore fields with NULLIf marked, NULL values in the JSON message coming in the request are not added as XML Elements to the XML message to be sent to the Backend API.

Ignore Empty Values

Field: Ignore EMPTY fieldsIf marked, empty values in the JSON message coming in the request are not added as XML Elements to the XML message to be sent to the Backend API.

Use xsi:nil

Field: Use xsi:nil=“true” for NULL valuesIf marked, the xsi:nil="true" attribute is used for NULL values in the JSON message coming in the request in the XML message to be sent to the Backend API. Otherwise, an empty element is added to the XML message for the relevant value.
Activating this value ensures that values sent as null in the JSON message are transmitted with the xsi:nil="true" field added when converting to XML.

Target XPath

Field: Target XPathSpecifies where the XML obtained after converting the incoming JSON message to XML will be placed in the XML message expected by the SOAP service.

Replace Children

Field: Replace ChildrenIf the option is marked, the children of the Target XPath’s output element are deleted and the part converted from JSON is added in their place. Otherwise, the element is completely replaced.

Array Elements

Field: Paths for Arrays within messageSpecifies which parts in the JSON message should be interpreted as arrays. Each Path is written starting from the level of Target XPath (or from the top level if Target XPath is not given) and placing # between levels.Example: The expression "envelope#body#abc" indicates that the “abc” element inside “body” inside “envelope” will be processed as an array.
When Array Within Array: When there is an array within an array and some objects sometimes come as array sometimes as singular, it is written starting from the outermost Array’s path and when going down to the object below, #* expression must be added after array expressions. For example, if abc element is an array and def element inside it is an array, it should be written as "envelope#body#abc, envelope#body#abc#*#def" in order.