SOAP to REST transformation
SOAP APIs are commonly used to expose data within enterprises. With the rapid adoption of the REST APIs, API providers must be able to provide RESTful interfaces to their existing SOAP APIs instead of creating new REST APIs. Using the webMethods API Gateway SOAP to REST transformation feature, the API provider can either expose the parts of the SOAP API or expose the complete SOAP API with RESTful interface. You can customize the way the SOAP operations are exposed as REST resources. Also, you can generate the Swagger or RAML definitions for these REST interfaces.
Limitations
The following limitations apply when you perform a SOAP to REST transformation:
- When an API provider defines the mapping for the SOAP operation to the REST resource or method, the provider must specify either the path and the query parameters or the body. These mappings are used when you transform the incoming REST request to the SOAP request.
- If both path and query parameters and body are sent in the incoming REST request, then the path and the query parameters are ignored.
- If your REST resource accepts the
text/xml
content-type, then you cannot modify the default resource path and resource name that the system automatically generates. This name must be the same as the SOAP operation name. However, this limitation is not applicable for other content-types. - The HTTP method filters of the global policy are not applicable to the REST transformed method of the SOAP API.
- The REST (REST transformed SOAP operations) resources do not appear as general REST resources when filtered in the Scopes section of the API in webMethods API Gateway.
- You cannot apply the Inbound Authentication-Message policy to the SOAP operation enabled as REST.
- The SOAP services that have Web Services Interoperability Organization (WS-I) non compliant WSDLs cannot be REST-enabled.