HTTP status code “204 No Content” is returned and the URL of the new resource is returned in the “Location” HTTP header field.

GET /articles/AR-00001

Retrieves the article resource specified by the ID. HTTP status code “200 OK” and the JSON-encoded resource are returned. If no article with the given ID exists, HTTP status code “404 Not found” is returned.

This document fully describes the request at the point in the diagram marked by the asterisk ‘*‘. As you can see, every piece of data from the HTTP request was mapped to some element or attribute. The JSON body of the request was also parsed and translated into XML. (The same also automagically works with XML bodies – although no “translation” is really needed in this case: The XML document from the request body would simply be inserted below the <body> node, with type="xml".)

This XML document is then used as input for the XSL Transformation. The fine-grained structure now makes it very easy to access specific data, which keeps the stylesheets very brief and concise, as well as easy to develop.

Configuring the XSLT component

At this point, to comply with the REST interface described above, we manually need to configure the XSLT component of the rest2soap feature, mapping REST requests to SOAP operations. We create a file “request.xsl” describing the translation of the “in-between XML document” to SOAP:

Mapping REST to *Your* SOAP Web Service

To realize a REST interface for another SOAP web service, or to proxy other operations, some tweeks to the stylesheets above are needed.

A good way to develop the REST-to-SOAP and SOAP-to-REST XSLT documents, is to set

log4j.logger.com.predic8=debug, stdout

in “conf/log4j.properties“. This turns on debug output. (You need to restart Membrane for the setting to take effect.) It allows you to see the “in-between XML document” created internally: When passing the arrow marked with a star * in the diagram, this document will be written to the log (standard output in our case).

The document returned by the first request, the WSDL document, is a technical description of the web service, its data structures and operations. Amongst other things, it describes the structure of the SOAP requests and their responses. The SOAP requests, the second type of requests, actually contain data, initiate actions and actually perform the tasks of the web service.

Requests of both types are forwarded by the proxy to the backend service, as by any generic HTTP proxy.

Additionally, the WSDL document needs to be slightly modified by the proxy before it is returned to the caller: It contains the SOAP endpoint’s address (“http://www.thomas-bayer.com/axis2/services/BLZService&#8221; in the example) and therefore influences the second type of requests. As we want these requests to be sent from the client to the proxy instead of directly to the backend service, we have to change this address to point to the proxy instead of the backend service:

Of course, you can use any SOAP client, for example soapUI, to access the service via the proxy: Simply specify the WSDL location using the proxy’s address (http://localhost/axis2/services/BLZService?wsdl or use the proxy’s qualified hostname).

The Next Steps

Adding additional features to the proxy is also very simple. We can, for example, change conf/proxies.xml to

The change will be automatically be picked up by Membrane within a few seconds. With the validator interceptor, Membrane will perform XML Schema validation on both requests and responses, ensuring that all requests and responses adhere to the data structures and rules documented in the WSDL document and the referenced XML Schema documents. This can, for example, help you protect your web service against certain kinds of attacks.