Bridging Web 2.0 and SOA using WebSphere DataPower

Learn how to build a JSON-enabled RESTful service on an IBM® WebSphere® DataPower® SOA Appliance, bridging it to a SOAPful backend Web service. Sample REST/JSON code is included to demonstrate best practices, along with explanations of how the example was implemented and configured. REST and Web 2.0 is supported on firmware level 3.8.0 or higher (sample created with 4.1.2). This content is part of the IBM WebSphere Developer Technical Journal.

Robert Peterson (rrpeters@us.ibm.com), Tivoli Integration Architect, IBM

Robert R. Peterson is an Integration Architect for Tivoli’s monitoring and application discovery portfolio. He is a frequent conference speaker, author, and IBM Master Inventor with over fifty filed patent applications. You can read more about Robert on his website.


developerWorks Contributing author
        level

Gerald Kaplan (kaplang@us.ibm.com), DataPower Technical Specialist, IBM

Gerald Kaplan is a Senior IT Specialist with a focus on IBM WebSphere DataPower service-oriented architecture (SOA) appliances. He joined IBM in 2006 and has more than 25 years of experience in software development and engineering. He is the author of the DataPower Proof of Technology, as well as several other IBM Redbooks publications.



21 September 2011

Introduction

Representational State Transfer (REST) is an important Web 2.0 technology that has become a popular alternative to other Web-based services, such as SOAP-based Web services and Enterprise JavaBeans (EJB). Many Internet-facing companies provide REST-based services; a common scenario is to expose a RESTful interface in front of an existing legacy system or peer system (SOAPful services). This article briefly explains what it means to be "RESTful," and then provides a comprehensive example of how to use an IBM WebSphere DataPower SOA Appliance to expose a RESTful facade (with JSON as the representational format) to bridge an existing SOAPful Web service.

Web 2.0 includes a proliferation of new technologies; some of them brand new and others old but newly invigorated as they are applied to Web 2.0. There is a growing demand to use these new protocols and technologies to interact with existing enterprise systems. DataPower is uniquely positioned to bridge Web 2.0 and SOA. DataPower can service Web 2.0 requests, such as an ATOM feed message or a REST invocation, and bridge to enterprise protocols, such as Web services, JMS, or even mainframe connectivity (for example, with IMS Connect). The case this article addresses is that of bridging REST client requests, which use JSON as the representational format, to a traditional SOAPful Web service back-end system.

REST overview

REST is a term coined by Roy Fielding in his Ph.D dissertation, and it denotes an architectural style for Web services and applications that manipulate media content. It can be considered a set of best practices for using the HTTP specification (RFC 2616) as an application layer protocol. There are no standards or APIs, and the primary ingredients are found in all HTTP-based Web applications and services. A good analogy for REST is "object-oriented" Web programming in which the resource specified by the URI is the object, the method is specified by the HTTP verb, and the parameters are specified by the HTTP headers, such as Accept or the URI query. Finally, the HTTP response code is the return code. For example, the following RESTful HTTP request results in the HTTP 201 (created) response code:

PUT /library/book/9780596529260 HTTP 1.1
Content-Type: application/json
Accept: text/xml
....
{ "name" : "Treasure Island" }

A Web service provider (and consumer for that matter) will pay close attention to the following RESTful precepts:

Named resources
Computation is over Web resources that are named through URIs.
  • A resource is anything important enough to be referenced as a thing in itself, such as /software/releases/1.0.3.tar.gz, /weblog/jim/2008/12/24/0300, or /bug/12345.
  • Consumers interact with resources using their URIs and the uniform interface.
Uniform interface
Web resources are accessed through a generic interface that mimics the CRUD persistent storage pattern:
  • GET -- Retrieve a resource representation.
  • POST -- Create a new resource.
  • PUT -- Modify or create a new resource (if client can make URI).
  • DELETE -- Remove an existing resource.
  • HEAD -- Retrieve metadata-only representation (can just be headers).
Interconnected resource representations
URL links interconnect resources, thereby driving all state transfers.
  • Representations are hypermedia (consider the duality of XHTML and micro-formats).
  • A web of resources.
  • Axiom: "Hypermedia as the engine of application state" -- Roy Fielding.
  • Application state is therefore the pathway the client follows, not an HTTP session on a server.
  • Cookies break the REST model of state transfer.
Stateless
Each request stands on its own without correlation to the server-side state.
  • States of a server are represented by URI addressable resources.
  • Every HTTP request happens in complete isolation, and is not dependent on previous requests.
  • Client moves through states by navigating representational formats (URIs) or going to known waypoints.
  • Consider the FTP "working directory" as an analogy.
  • Easy to distribute a stateless application across load-balanced services.
  • Client is in charge of managing "application state," while server manages "resource state."

The result of applying RESTful precepts is not only the simplicity and consistency of developing and invoking Web services, but also an advantage in service performance. When RESTful services are deployed, they can naturally participate in the HTTP caching mechanism. Therefore caching intermediaries or response caches can leverage the additional information supplied not only by the HTTP method, but also by the cache control headers (including the last-modified header) rendered by the RESTful service provider. Leveraging caching in this way can dramatically improve response time. In addition, the stateless nature of RESTful service not only makes horizontal scaling trivial, but also eases the burden on load balancers (no session affinity is necessary), and allows application-aware caching intermediaries to execute more efficiently because the payload often does not have to be processed or parsed.

Exposing REST with DataPower

Figure 1 shows an overview of WebSphere DataPower exposing a REST facade against a SOAPful Web service as the back end. The representational format (media type) used by the REST facade is JSON. The Multi-Protocol Gateway accepts RESTful method requests (GET, PUT, POST, DELETE) from the service consumer and then transforms the requests to corresponding SOAP requests. The Web Service Proxy is optional; the SOAP requests could be sent directly to the back end, but this practice is strongly discouraged because the configuration might require monitoring or security in the future. Thus, a best practice is to include a Web Service Proxy as part of a REST transformation configuration.

Figure 1. Topology of a RESTful client passing JSON to DataPower, which mediates a SOAPful Web service
RESTful facade topology

The ProjectService example

For simplification, the example configuration shown in this article and the accompanying download material does not include a WS-Proxy. However, its use is recommended for production environments.

The remainder of this article uses a common example to show how DataPower can expose a RESTful Web service interface, enabled for JSON, for a SOAPful Web service back end. The sample ProjectService Web service is a simple project organizer with which projects can be created, edited, and queried. The operations available for ProjectService are shown in Table 1.

Operations available for DemoService
OperationDescription
createProjectCreates a project on the server consisting of a project name, description, and identifier. The identifier is generated and returned in the response.
updateProjectMakes a change to a project. The project identifier, name, and description must be provided.
getProjectFetches name and description of a project. The identifier of the project must be provided in the request.
listProjectReturns all projects.
deleteProjectRemoves a project from the server. The identifier of the project must be provided in the request.

The next sections show how to map these operations to a REST interface consisting of all the HTTP methods, GET, POST, PUT, and DELETE.

Install ProjectService

Download the sample ProjectService application included with this article, and then follow these steps to install ProjectService.ear on WebSphere Application Server V7 or later:

  1. From the Admin console, select Applications > Install New Application > New Enterprise Application.
  2. Select Browse and then select the ProjectService.ear file, as shown in Figure 2.
  3. Select Next.
    Figure 2. Install ProjectService application
    Install ProjectService application
  4. Select Fast Path and click Next.
  5. Accept the defaults on all subsequent pages, then click Finish.
  6. After the installation completes successfully, click Save to save the changes to the master configuration.
  7. Navigate to Applications > Application Types > WebSphere enterprise applications and Start ProjectServiceEar.

Verify application installation

It’s a good idea to verify that ProjectService is up and running. One way to verify this is to request the service’s WSDL. In a browser, navigate to http://MyAppServer:9080/ProjectService/ProjectService?WSDL. If the service’s WSDL is displayed in the browser, then the service is up and running. Alternatively, you can use soapUI, a freely available vendor tool to test the service. A soapUI project for the ProjectService is available in the downloads material included with this article. Once downloaded, select File > Import Packed Project and select soapUITestSOAP.zip from the soapUI File menu.

Import example DataPower configuration

To import the DataPower configuration into your appliance:

  1. In the DataPower Admin Console, select Administration > Configuration > Import Configuration.
  2. Click Browse, select RESTDataPowerExportV2.zip (included in the download file), and then select Next:
    Figure 3. DataPower domain import
    Figure 3. DataPower domain import
  3. Select Import.

REST Multi-Protocol Gateway

If you inspect the Multi-Protocol Gateway service definition by selecting the Advanced tab, you'll notice an option label "Process messages whose body is empty," as shown in Figure 4. This option is useful for message patterns that can include bodiless requests and responses. This is common with RESTful Web services where messages may or may not include a body, but still require the processing policy to run in order to perform mediations. Unlike SOAPful Web services, which always have a payload (message body), RESTful Web services often, but not always, have a message body, as with HTTP DELETE.

Since your RESTful façade will support HTTP DELETE and GET, you must configure the service to support bodiless messages. If you don't select this option, DataPower defaults to a processing mode called "One way exchange pattern," in which messages flow straight to the backside server, bypassing any processing rules. You also have to configure the HTTP frontside handler to accept the HTTP methods that you plan on supporting in your policy. In addition, since you are dealing with JSON as the representational format, the request and response payload types will be non-XML.

Figure 4. Process messages whose body is empty
Process messages whose body is empty

Backend URL and front side handler port

On the main Multi-Protocol Gateway page, change the backend URL to match the application server that your ProjectServiceEar project is running on, as shown in Figure 5.

Figure 5. Updated backend URL
Figure 5. Updated backend URL

You can optionally change the port that the Multi-Protocol Gateway is listening to for request REST messages. The imported configuration uses port 44601, but you can change this by selecting restfulProjectService_FSH in the drop-down under Front Side Protocol and then selecting the ellipses (...) and entering the Port Number desired.

Rewriting the URL

The ProjectService specifies /ProjectService/ProjectService as the service URI, while RESTful Web services use URIs not as the service end-point, but rather as the resource to apply the uniform interface. Because of this dramatic difference in usage, a URL rewrite policy is associated with the multi-protocol gateway, as shown in Figure 6 below. In this way, all incoming RESTful URI's are rewritten to the single SOAP service URI.

Figure 6. URL rewrite policy attached to the Multi-Protocol Gateway
Figure 6. URL rewrite policy attached to the Multi-Protocol Gateway

Using REST verbs

When building a RESTful service, it is a best practice to set up processing rules for each HTTP method. This is because the REST uniform interface can be applied to each RESTful URI but require different processing behavior, such as HTTP DELETE on /library/book/12345679001 and HTTP GET on /library/book/12345679001.

The Multi-Protocol Gateway matches on HTTP methods by creating a Match Action with a Matching Rule and then specifying a Matching Type of HTTP Method for each REST verb supported by the service, as depicted in Figure 7. This matching rule can be combined with any other match criteria to create personalized processing rules based on URI and/or HTTP headers.

Figure 7. A Multi-Protocol Gateway using the HTTP method match criteria
A Multi-Protocol Gateway using the HTTP method match criteria

The next sections describe the implementation of the REST Multi-Protocol Gateway policy, shown in Figure 8. They can be used as an exercise in DataPower REST development, as a working configuration to use as a starting point for other REST projects, or simply as a gauge for what transformation from REST/JSON to SOAP looks like with DataPower.

Figure 8. REST/JSON processing policy
REST/JSON processing policy

These sections are presented by each DataPower processing rule: POST, GET, DELETE, and PUT. The same format is used to describe the implementation for each processing rule, which includes:

If you prefer to use soapUI instead of cURL to test the REST API, a soapUI projecte has been included in the download material, called soapUITestREST.zip.

  • Request payload: An example of the REST request payload using JSON as the representational format.
  • Response payload: An example of the REST response payload or headers.
  • Actions: Includes an image representing the processing rule with its processing actions. The numbering indicates the sequence of the processing actions.
  • Code listings: For the stylesheets defined in the processing rules. Each listing is numbered according to the sequence numbers in the corresponding Actions figure.
  • Test command:cURL is a command-line tool that can be used to send http requests to test the REST operations. An example cURL command to invoke the REST service with the corresponding HTTP method.

POST

The POST processing rule corresponds to the createProject operation for the SOAP API.

  • Request payload: JSON project object
    Listing 2. POST request payload
    { "description":"My Research Project", "owner":"Alice" }
  • Response payload: None, but the location HTTP header should give the URL of the newly created resource.
  • Actions:
    Figure 9. POST request processing rule
    POST request processing rule

    (1) convert-http action: This http-convert action specifies JSON (Figure 10 below) as the message encoding that automatically parses and transforms it into JSONx, which is an IBM internal standard format for representing JSON as XML. Once the JSON is transformed into JSONx, the usual DataPower transformation capabilities are available to further process the message as XML if necessary. For the JSON request payload in Listing 2, the resulting JSONx is shown in Listing 3.

    Listing 3. JSONx
    <?xml version="1.0" encoding="UTF-8"?>
    <json:object xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd"
                 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx">
      <json:string name="description">Research of ancient cultures</json:string>
      <json:string name="owner">Alice</json:string>
    </json:object>
    Figure 10. JSON specified as the default input encoding
    JSON specified as the default input encoding

    (2) createProjJSONx2SOAP.xsl transform: This custom stylesheet provided by the user transforms the REST project payload (now as JSONx) to the equivalent SOAP payload. The project description and owner are copied from the JSONx message request.

    Listing 4. createProjJSONx2SOAP.xsl
    <xsl:stylesheet xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:dp="http://www.datapower.com/extensions"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx" 
    		extension-element-prefixes="dp"
      exclude-result-prefixes="dp" version="1.0">
      <xsl:template match="/">
      
        <xsl:variable name="url" select="dp:variable('var://service/URL-in')"/>
        <xsl:message><xsl:value-of select="$url"/></xsl:message>
    
        <soapenv:Envelope>
          <soapenv:Body>
            <updateProjectRequest xmlns="http://www.ibm.com/datapower/ProjectService/">
              <project>
                <id>
                  <xsl:value-of select="substring-after($url,'/projects/')"/>
                </id>
                <description>
                  <xsl:value-of select="/json:object/json:string[@name='description']"/>
                </description>
                <owner>
                  <xsl:value-of select="/json:object/json:string[@name='owner']"/>
                </owner>
              </project>
            </updateProjectRequest>
          </soapenv:Body>
        </soapenv:Envelope>   
    
      </xsl:template>
    </xsl:stylesheet>

    (3) Setvar action: This action sets the SOAPAction header to http://www.ibm.com/datapower/ProjectService/createProject before the message is sent to the ProjectService application.

    POST response rule: set-location-header.xsl transform: This stylesheet selects the ID from the SOAP response and sets the location HTTP header with the URL for the newly created resource.

    Listing 5. set-location-header.xsl
    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet xmlns:dp="http://www.datapower.com/extensions"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform" extension-element-prefixes="dp"
        exclude-result-prefixes="dp" version="1.0">
    
        <xsl:template match="/" 
    xmlns:proj="http://www.ibm.com/datapower/ProjectService/">
            <dp:set-http-response-header name="'Location'" 
    			value="concat('/projects/',//proj:id)"/>
        </xsl:template>
    
    </xsl:stylesheet>

    An example JSON request is needed to test the POST REST method. A text file called RESTPostRequest.json is provided in the download archive under the folder named RESTRequests with the contents of Listing 2; for example, RESTPostRequest.json. To send the request to DataPower, use this cURL command:

    curl --data-binary @RESTPostRequest.json http://DPHOST:44601/projects -v

    The -v flag enables you to see the headers returned from DataPower. There is no response payload, but pay special attention to the Location header, which returns the URL of the newly created project. For example, it returns /projects/3 when the third project is created.

GET

The GET processing rule corresponds to the getProject and listProject operations for the SOAP API. It can either retrieve a single project or a list of projects (collection).

In order to test listing mulitple projects, add another project using the POST method as shown in the last section. Use a project called “Training Project” owned by “Barbara.”

  • Request payload: None.
  • Response payload: JSON Project, JSON Project List
    Listing 6. GET JSON project response payload
    { "id":1, "name":"My Research Project", "owner":"Alice" }
    Listing 7. GET JSON project list response payload
    [ { "id":1, "name":"My Research Project", "owner":"Alice" },
    
    { "id":2, "name":"Training Project", "owner":"Barbara" } ]
  • Actions:
    Figure 11. GET processing rule
    GET processing rule

    (1) rest-get-to-soap.xsl transform: This stylesheet constructs the SOAP request to get a project or list all projects. It corresponds to the getProject and listProject SOAP operations. The ID is retrieved from the URL and then either a listProjectRequest or getProjectRequest SOAP payload.

    Listing 8. rest-get-to-soap.xsl
    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:dp="http://www.datapower.com/extensions" 
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        extension-element-prefixes="dp" exclude-result-prefixes="dp" version="1.0">
    
        <xsl:template match="/">
    
          <xsl:variable name="url" select="dp:variable('var://service/URL-in')"/>
    
          <soapenv:Envelope>
            <soapenv:Body>
               <xsl:choose>
                   <xsl:when test="contains ($url, '/projects/')">
                      <getProjectRequest
    xmlns="http://www.ibm.com/datapower/ProjectService/">
                         <id>
                           <xsl:value-of select="substring-after($url,'/projects/')"/>
                         </id>
                      </getProjectRequest>
                      <dp:set-http-request-header name="'SOAPAction'"
    value="'http://www.ibm.com/datapower/ProjectService/getProjects'"/>
                   </xsl:when>
                   <xsl:otherwise>
                      <listProjectsRequest 
    xmlns="http://www.ibm.com/datapower/ProjectService/"/>
                      <dp:set-http-request-header name="'SOAPAction'" 
    value="'http://www.ibm.com/datapower/ProjectService/listProjects'"/>
                   </xsl:otherwise>
               </xsl:choose>
            </soapenv:Body>
          </soapenv:Envelope>   
    
      </xsl:template>
    
    </xsl:stylesheet>

    (2) Method Rewrite advanced processing action: Prior to sending the SOAP message to the back end, you need to rewrite the HTTP method from the originating GET to HTTP POST that the SOAP service expects. Do this by using the Method Rewrite advanced processing action. You can even do this by setting var://service/protocol-method to the value POST.

    GET response rule(1) listProjResp2JSONx.xsl: Once the SOAP response is retrieved from the back end, it needs to be transformed into a JSONx RESTful payload. The project ID, description, and owner are retrieved from the input SOAP message and are used to construct the JSONx REST response. This process is repeated if a project list is being returned.

    Listing 9. listProjRest2JSONx.xsl
    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
      <xsl:template match="/">
        <json:array xsi:schemaLocation="http://www.datapower.com/schemas/json jsonx.xsd"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx">
            <xsl:for-each select="//*[local-name()='project']">
                <json:object>
                    <json:number name="id">
                        <xsl:value-of select="*[local-name()='id']"/>
                    </json:number>
    
                    <json:string name="name">
                        <xsl:value-of select="*[local-name()='description']"/>
                    </json:string>
    
                    <json:string name="owner">
                        <xsl:value-of select="*[local-name()='owner']"/>
                    </json:string>
                </json:object>
            </xsl:for-each>
        </json:array>
      </xsl:template>
    </xsl:stylesheet>

    GET response rule(2) jsonx2json.xsl: Now that you have the payload converted to JSONx, apply the DataPower supplied jsonx2json.xsl stylesheet to convert the result to JSON, which the client expects. To send a single GET request to DataPower, use this cURL command (the project ID is 1 in this example):

    curl http://DPHOST:44601/projects/1

    To send a GET request for a list of all projects, use this cURL command; notice the project ID is omitted:

    curl http://DPHOST:44601/projects

DELETE

The DELETE processing rule corresponds to the removeProject operation for the SOAP API.

  • Request payload: None.
  • Response payload: HTTP 204 (No Content) response code.
  • Actions:
    Figure 12. DELETE processing rule
    DELETE processing rule

    (1) rest-delete-to-soap.xsl transform: This stylesheet constructs the SOAP payload to delete a project. It corresponds to the deleteProject SOAP operation. The project ID is retrieved from the URL and then used to construct the SOAP payload.

    Listing 10. rest-delete-to-soap.xsl
    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
        xmlns:dp="http://www.datapower.com/extensions" 
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        extension-element-prefixes="dp" exclude-result-prefixes="dp" version="1.0">
    
        <xsl:template match="/">
    
            <xsl:variable name="url" select="dp:variable('var://service/URL-in')"/>
    
            <soapenv:Envelope>
                <soapenv:Header/>
                <soapenv:Body>
                    <deleteProjectRequest 
    xmlns="http://www.ibm.com/datapower/ProjectService/">
                        <id>
                            <xsl:value-of select="substring-after($url,'/projects/')"/>
                        </id>
                    </deleteProjectRequest>
                </soapenv:Body>
            </soapenv:Envelope>  
    
        </xsl:template>
    </xsl:stylesheet>

    (2) Setvar action: This action sets the SOAPAction header to http://www.ibm.com/datapower/ProjectService/deleteProject before the message is sent to the ProjectService Web service proxy.

    (3) Method Rewrite advanced processing action: Prior to sending the SOAP message to the backend, you need to rewrite the HTTP method from the originating DELETE to HTTP POST, which the SOAP service expects. Do this by using the Method Rewrite advanced processing action. You can even do this by setting var://service/protocol-method to the value POST.

    DELETE response rule(1) set-response-code.xsl: Once the SOAP response is retrieved from the backend, it needs to be transformed into a RESTful response code, which is typically 204 (No Content) when a DELETE is performed. To send a DELETE request to DataPower, use this cURL command:

     curl -X DELETE http://DPHOST:44601/projects/1

    (If you get this error message: curl: (18) transfer closed with outstanding read dat remaining, this is due to a known WebSphere DataPower issue which should be fixed in an upcoming release. The DELETE operation should still succeed.)

PUT

The PUT processing rule corresponds to the updateProject operation for the SOAP API.

  • Request payload: JSON project object
    Listing 11. PUT request payload
     { "id":2, "name":"Training Project", "owner":"Chandra" }
  • Response payload: None.
  • Actions:
    Figure 13. Put processing rule
    Put processing rule

    (1) convert-http action: This http-convert action specifies JSON as the message encoding, which automatically parses and transforms it into JSONx, an IBM internal standard format for representing JSON as XML. Once the JSON is transformed into JSONx, the usual DataPower transformation capabilities are available to further process the message as XML if necessary.

    (2) updateProjJSONx2SOAP.xsl transform: This stylesheet transforms the REST JSONx project payload to the equivalent SOAP payload. The project ID, project description, and owner are copied from the JSONx REST request.

    Listing 12. updateProjJSONx2SOAP.xsl
    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:dp="http://www.datapower.com/extensions"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns:json="http://www.ibm.com/xmlns/prod/2009/jsonx" 
    		extension-element-prefixes="dp"
      exclude-result-prefixes="dp" version="1.0">
      <xsl:template match="/">
            
        <xsl:variable name="url" select="dp:variable('var://service/URL-in')"/>
        <xsl:message><xsl:value-of select="$url"/></xsl:message>
    
       <soapenv:Envelope>
         <soapenv:Body>
             <updateProjectRequest xmlns="http://www.ibm.com/datapower/ProjectService/">
               <project>
                 <id>
                   <xsl:value-of select="substring-after($url,'/projects/')"/>
                 </id>
                 <description>
                  <xsl:value-of select="/json:object/json:string[@name='description']"/>
                 </description>
                 <owner>
                   <xsl:value-of select="/json:object/json:string[@name='owner']"/>
                 </owner>
               </project>
             </updateProjectRequest>
         </soapenv:Body>
       </soapenv:Envelope>    
    
      </xsl:template>
    </xsl:stylesheet>

    (3) Setvar action: This action sets the SOAPAction header to http://www.ibm.com/datapower/ProjectService/updateProject before the message is sent to the ProjectService Web service proxy.

    (4) Method Rewrite advanced processing action: Prior to sending the SOAP message to the back end, you need to rewrite the HTTP method from the originating PUT to HTTP POST, which the SOAP service expects. Do this by using the Method Rewrite advanced processing action, or by setting var://service/protocol-method to the value PUT.

    PUT response rule(1) set-response-code.xsl: Once the SOAP response is retrieved from the back end, it needs to be transformed into a RESTful response code, which is typically 204 (No Content) when a PUT is performed. An example request is needed to test the PUT REST method;l RESTPutRequest.json has been provided in the download archive under RESTRequests which is identical to Listing 11. Assuming the request payload was saved as RESTPutRequest.json, to send the request to DataPower, use this cURL command:

    curl -X PUT --data-binary @RESTPutRequest.json http://DPHOST:44601/projects/2

    A blank response is normal and expected.

Conclusion

This article explained how IBM WebSphere DataPower fits in the Web 2.0 space, provided an overview of REST, described the recommended patterns to use for exposing REST and JSON with WebSphere DataPower, and included a comprehensive example with a DataPower domain export and the ProjectService Web service back-end application. You should now have a good understanding of what REST is, and how you can develop REST services on WebSphere DataPower so you can configure your own Web 2.0 appliance.


Download

DescriptionNameSize
Code sampleDP-REST-ExampleV2.zip538 KB

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=760766
ArticleTitle=Bridging Web 2.0 and SOA using WebSphere DataPower
publish-date=09212011