Import the SoapUI project CustomerServiceCRM-soapui-project.xml from the location chapter-5getting-readyexposing-restful-servicesoapui into your SoapUI. Start the mock service CustomerServiceSOAP MockService.

Import the base OSB project containing the right folder structure and the necessary XQuery transformations into Eclipse from chapter-5getting-readyexposing-restful-service.

We will start with the business service, which will wrap the SOAP-based web service of the CRM system (the soapUI mock service).

In Eclipse OEPE, perform the following steps:

The completed message flow definition is shown in the following screenshot:

Now let's test our RESTful service. There are multiple ways for testing a RESTful service.

For testing the GET method, we can use a Web browser and enter the following URL: http://localhost:7001/exposing-restful-service/CustomerService?id=100:

For testing the other implemented HTTP methods, we can use the Service Bus console.

To test the PUT method, perform the following steps in Service Bus console:

Testing the other HTTP methods is similar to the PUT, just replace the HTTP method and pass another message. To test the DELETE and GET, enter the value of the query string (that is, id=100) into the query-string field.

In this recipe, we created a REST interface for an existing SOAP service. We have mapped each of the available HTTP methods to one of the CRUD operations of the customer service.

The HTTP methods we implemented are PUT, POST, DELETE, and GET.

Working with the HTTP methods is similar to working with a WSDL with multiple operations. But we can't use an operational branch for handling the different methods; we have to use a conditional branch. The conditional branch decides which HTTP method has been passed and triggers the right behavior.

For each method we have to transform the message we get through the RESTful interface to the message the backend SOAP-based web service expects. For that, we have used the Replace action together with XQuery scripts.

For the GET and DELETE method, all the necessary values are passed in the query string, that is, in the URL of the request. For example, to read the customer with id=100, we have defined and used the following URL:

http://localhost:7001/exposing-restful-service/CustomerService?id=100

The request URL will end up in the $inbound variable, the part with the information about the request is shown here:

<con:transport>
    <con:uri>/exposing-restful-service/CustomerService</con:uri>
    <con:request>
    <tran:headers>
        <http:Content-Type>text/plain; charset=utf-8</http:Content-Type>
    </tran:headers>
    <tran:encoding>utf-8</tran:encoding>
    <http:query-string>id=100</http:query-string>
    <http:query-parameters>
        <http:parameter name="id" value="100"/>
    </http:query-parameters>
    <http:http-method>GET</http:http-method>
    </con:request>
</con:transport>

We can see that the there is a separate element http:query-string only holding the value of the query string. Additionally there is a http:query-parameters collection with one element for each parameter.

In the implementation of the GET method, we have used the http:query-string element to pass the value of the query-string to the XQuery script by using the following XPath expression:

$inbound/ctx:transport/ctx:request/http:query-string/text()

The XQuery then uses the following FLOWER expression to create the criteria structure to be passed to the SOAP web service of the CRM system.

<criterias>
    {
    for $nameValue in fn:tokenize($queryString,"&amp;")
    return 
        <criteria>
            <criteriaField>{ fn:substring-before($nameValue,'=') }
            </criteriaField>
            <criteriaValue>{ fn:substring-after($nameValue,'=') }</criteriaValue>
        </criteria>
    }
</criterias>

The implementation of the DELETE method is using the http:query-parameters collection to retrieve the value of the id parameter using the following expression:

$inbound/ctx:transport/ctx:request/http:query-parameters/http:parameter/@value[$inbound/ctx:transport/ctx:request/http:query-parameters/http:parameter/@name='id']

For the PUT and POST method, the message is passed as an XML fragment, which will end up in the $body variable in the message flow. The following screenshot shows the content of the $body for the PUT request when logged through a Log action.

In the previous recipe, we used the query string part of the URL to pass the values to the GET and DELETE method. Another way of passing these values is as so-called clean URLs, which are purely structural URLs that do not contain a query string but instead define the path of the resource through the URL. So instead of using the following URL for the GET:

http://localhost:7001/exposing-restful-service/CustomerService?id=100

we could use a clean URL, such as this one:

http://localhost:7001/exposing-restful-service/CustomerService/id/100

Even if the request URL is longer, the existing proxy listening on Endpoint-URI /exposing-restful-service/CustomerService will still be triggered. The interesting part of the $inbound variable in this case would hold the following values:

<con:transport>
    <con:uri>/exposing-restful-service/CustomerService</con:uri>
    <con:request>
        <tran:headers>
            <http:Content-Type>text/plain; charset=utf-8</http:Content-Type>
        </tran:headers>
        <tran:encoding>utf-8</tran:encoding>
        <http:relative-URI>id/100</relative-UR>
        <http:http-method>GET</http:http-method>
    </con:request>
</con:transport>

We can see that the part of the path after the Endpoint-URI of the proxy can be found in the http:relative-URI element. Using a tokenize function, it's easy to access the different values, for example, for the value of the id we could use:

fn:tokenize($inbound/ctx:transport/ctx:request/http:relative-URI/text(),'/')[2]