Slide 1: ZE752 Unit 1 Transcript

ZE752 Unit 1 Transcript
Slide 1
REST and JSON support for

Web 2.0 and mobile
applications
© Copyright IBM Corporation 2016

Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0

Course materials may not be reproduced in whole or in part without the prior written permission of IBM.
Slide 2
How to check online for course material updates
Instructions
1. Enter this URL in your browser:

ibm.biz/CloudEduCourses
2. Find the product category for your course, and
click the link to view all products and courses.
3. Find your course in the course list and then click
the link.
4. The wiki page displays information for the course.
If the course has a corrections document, this
page is where it is found.
5. If you want to download an attachment, such as a
Note: If your classroom does not course corrections document, click the
have internet access, ask your Attachments tab at the bottom of the page.
instructor for more information.
6. To save the file to your computer, click the

document link and follow the prompts.
REST and JSON support for Web 2.0 and mobile applications © Copyright IBM Corporation 2016

Slide 3
Unit objectives
• Add support to DataPower services to support REST applications
• Describe how to integrate with systems by using RESTful services
• Use the DataPower gateway to proxy a RESTful service

Slide 4
Alternatives to SOAP-based web services

• SOAP-based web services work well in certain situations:
▪ Provide an interoperable communications platform between computer
systems
▪ Communicate between different parts of a business process engine and
business process management (BPM) solutions
• However, web services are at times too complex for human-facing
applications:
▪ Web services do not address the presentation layer; extra programming is
needed to support human-to-computer communication
▪ XML-based data structures tend to be more verbose than necessary for
simple clients, such as JavaScript applications in a web browser-to-server
scenario
• For rich web applications, a simpler communication format accessible
to every developer skill level is needed
Service-oriented architecture (SOA) focuses on interoperability between computer-to-computer

interactions. SOAP-based web services are the common way to deliver this capability.
The industry has learned that SOAP-based web services work well in certain situations, such as:
1) Providing an interoperable communications platform between computer systems, and
2) Communicating between different parts of a business process engine and business
process management (BPM) solutions.
The industry has also learned that web services are at times too complex for human-facing
applications. For example, web services do not address the presentation layer; the programming
layer that supports human to computer communication. Furthermore, XML-based data structures
tend to be more verbose than necessary for simple clients, such as JavaScript applications in a
web browser-to-server scenario.
Web 2.0 applications, which frequently use the REST paradigm, focus on a richer experience for
the user. As such, the application protocols and data formats that are used in an enterprise SOA
scenario do not always fit the needs of Web 2.0 applications.
For example, SOAP has been adopted as a standard for encapsulating web services messages.
Its structure is intentionally verbose in order to convey metadata about the call between
computers. The cost that is involved in larger message structures is offset by the need for client
and server developers to readily consume the message.
The overriding priority in Web 2.0 applications is responsiveness. Therefore, Web 2.0
applications tend to use simplified data structures and application formats in order to improve the
development time of the application, and the processing speed on the client.
The challenge is that for rich web applications, there is a need for a far simpler communications
approach accessible to every developer skill level. REST is part of the solution to this
requirement.

Slide 5
Web SOA (Web 2.0) versus Enterprise SOA
Ajax
Atom
JavaScript
RSS
XML
JSON Enterprise SOA
REST
Web-SOA
bridge
WSDL J2SE
Web SOA
SOAP Java EE
WS-* JMS
JDBC
This slide maps the technologies that are most popular with each side's view of SOA. Whereas
enterprise SOA focuses on the integration of information systems and applications, web SOA
focuses on sharing information between rich, interactive web applications. Enterprise SOA deals
more with computer-to-computer systems on the back end, while web SOA focuses on delivering
a rich experience to the user.
With this view of the world, web SOA and enterprise SOA can coexist. By using bridging
applications, the services within an enterprise can be exposed through a user-friendly, interactive
web application to the customer.
The terms that are listed in each domain are not meant to be comparable on a one-to-one basis.
For example, it does not make sense to compare Ajax with RSS, or WSDL with Java Platform,
Enterprise Edition (J2EE). Not all technologies are specific to their domains as well. XML is
widely used in both web SOA and enterprise SOA environments.

Slide 6
Web SOA protocols and standards

Transport and invocation protocols and techniques
• Hypertext Transfer Protocol (HTTP, HTTPS)
• Representational State Transfer (REST)
• Comet
Data format standards and techniques

• Extensible Markup Language (XML)
– Plain old XML over HTTP (POX/HTTP)
• JavaScript Object Notation (JSON)
• JSON-RPC
• Bayeux
• Really Simple Syndication (RSS)
• Atom
Web 2.0 application design and coding are governed by various protocols, standards, and
techniques.
HTTP and HTTPS are the protocols for communications. REST and Comet are techniques for
programming the interactions.
REST is one of the primary subjects of this unit.
Comet is another programming and design technique. It is a model in which a web server can
push data to the browser, without the browser explicitly requesting it.
Remember that plain-old XML over HTTP is not a standard; it simply uses HTTP to transfer raw
XML data in a format specific to the application.
JavaScript Object Notation, more commonly known as JSON, is a data formatting standard that
reflects the data.
JSON-RPC is a remote procedure call (RPC) protocol that is coded in a JSON format.
Bayeux is a JSON-based protocol for publish/subscribe event management. It uses Ajax and
Comet.
RSS is a web feed format for supporting syndications, such as blogs and news. It uses an XML-
based structure. There are many versions of RSS, and not all are compatible.
The term “Atom” refers to two related standards. The Atom Syndication Format is an XML
structure for web feeds. The Atom Publishing Protocol is a protocol for creating and updating web
resources. Atom was developed as an alternative, and improvement to RSS.

Slide 7
Growth of mobile clients

Different platforms and form factors
• Smartphones
• Tablets
Different types of interfaces

• Mobile web
 Web browser on mobile device
 Might be the same as the desktop browser page,
or might be customized for the device size and
screen resolution
• Hybrid, native
 Mobile application that is written for the specific
device, usually by using an SDK
 Not browser-based
• Mobile clients commonly use REST and JSON
 Desktop web browser interface still needs to be available
Not only has the type of application changed, so has the client platform. Many clients now use
smartphones and tablets, in addition to their desktop browsers.
Mobile clients might continue to use a web browser interface, but use it from their device instead
of a desktop. The browser interface might be the same as the desktop browser, or it might be
customized to the device size and screen resolution.
Mobile applications can be developed that use the native capabilities of the device and look
different from the web browser interface. These types of applications are usually written by using
a software development kit (SDK).
Mobile clients usually use a REST and JSON interface.
Many companies decide to retain their browser interfaces to continue to support clients that are
still using desktop interfaces, while they offer a more user and device-friendly Mobile interface.

Slide 8
DataPower as the reverse proxy for Web 2.0 and mobile

clients
• Clients communicate with DataPower as if it is a REST or JSON
service
• Target DataPower service sends request to appropriate back end
▪ If necessary, converts REST or JSON to XML or web services
▪ Applies other mediation to message as needed (AAA, transform, filter)
REST/JSON
applications
REST
JSON
XML and web services

Browser applications
With Mobile clients, DataPower continues to play an intermediary role. Regardless of what type of
back-end application is eventually being accessed, the client interacts with DataPower as if it is
an actual REST and JSON application.
The targeted DataPower service converts the REST and JSON request to whatever format or
protocol the back-end application uses. For example, if the back-end application is web services,
the DataPower service converts the REST request into a web service call, and the corresponding
web services response to a REST response. Other typical mediations like AAA, routing, and
filtering can still be applied as needed.
The clients see only the DataPower service, and are not aware of the actual back-end
application. The back-end applications, regardless of technology, accept traffic only from the
gateway. This arrangement is commonly called a “reverse proxy”.

Slide 9
Securing the reverse proxy with IBM Security Access

Manager for Mobile
• Access Manager Reverse Proxy service can interact with IBM Security
Access Manager for Mobile to provide more security:
▪ One-Time Password (OTP)
▪ Multi-factor authentication (MFA) IBM Security
▪ Context-based access (CBA) Access Manager
for Mobile
appliance
Mobile and web

applications
REST Access Manager

Reverse Proxy
JSON service
By integrating with ISAM for Mobile, the Access Manager Reverse Proxy service can provide
more security support beyond forms authentication or HTTP basic authorization. This service and
ISAM for Mobile also supports more advanced protection such as One-Time Password (OTP),
Multi-factor Authentication (MFA), and Context-based access (CBA).
The Access Manager Reverse Proxy service itself can secure a directory tree-like structure of
web resources. Additionally, the Access Manager Reverse Proxy service can chain with a multi-
protocol gateway service to offer further mediation of the message contents.
The Access Manager Reverse Proxy service capabilities are similar to the capabilities of
WebSEAL. IBM Security Access Manager WebSEAL is a web server that applies fine-grained
security policy to the IBM Security Access Manager protected web object space. WebSEAL can
provide single sign-on solutions and incorporate back-end web application server resources into
its security policy.
The Access Manager Reverse Proxy service requires the ISAM Proxy module to be licensed and
installed on the gateway.

Slide 10
Introduction to REST
Representational State Transfer (REST) is an architectural style for
accessing resources across a network:
• Application state and functions are divided into resources
• Every resource is uniquely addressable with universal syntax
• All resources are accessible with a uniform, generic interface
• A client/server architecture with a pull-based interaction style
• Each request from the client to the server must contain all necessary
information to understand the request
▪ REST architectures cannot rely on stored context on the server
• REST is a design pattern, not a standard
• In a Web 2.0 context, REST describes a way to design web
applications that:
▪ Address resources through URIs
▪ Access resources through HTTP methods
Representational State Transfer (REST) is a style of software architecture for distributed

hypermedia systems such as the World Wide Web. The term Representational State Transfer
was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. Fielding is one of
the principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.
Representational State Transfer (REST) is an architectural style for accessing resources across a
network by incorporating the following guidelines. First of all, application state and functions are
divided into resources. Second, every resource is uniquely addressable with a universal syntax.
Third, all resources are accessible with a uniform, generic interface. Fourth, REST is part of a
client/server architecture with a pull-based interaction style. And finally, fifth, each request from
the client to the server must contain all necessary information to understand the request since
REST architectures cannot rely on stored context on the server.
Therefore, REST is actually a design pattern that uses these guidelines, and not a published
standard or product.
In a Web 2.0 context, REST describes a way to design web applications that address resources
through URIs and access these resources through HTTP methods.
It is worthwhile to point out that REST is not a protocol for invoking web services. In most
RESTful web service implementations over HTTP, clients use URL addresses as an abstraction
to a resource on the server. For example, each employee record can be addressed through a
URL. The HTTP methods are used to describe a particular action over the URL resource.
As IT professionals might expect, a REST architecture is not suitable for all types of web
services. REST works well in performing create, retrieve, update, and delete operations on
database entities. This model is less suited for services that provide complex business services
or aggregate functions, such as finding the average number of employees per department.
10

Slide 11
REST-style services
• GET • PUT
▪ Fetch a resource ▪ Update an existing resource
from the server ▪ Depending on the defined interface, can
▪ Idempotent also create a resource at a specific URL
▪ No side effects ▪ Idempotent
▪ Has side effect
• DELETE • POST
▪ Remove a resource ▪ Create a resource in this collection; the
from the server server picks the resource’s URL
▪ Idempotent ▪ Also, for invoking a function, “process this”
▪ Has side effect ▪ Non-idempotent
▪ Usually has side effects
Before discussing the REST style services, there are two other terms that are associated with
REST services. These terms do not come from Fielding's original PhD thesis on REST, but do
appear in a Request For Comment document (RFC 2616) and have been popularized through
books on RESTful web services.
The term "safe" means that if a particular HTTP method is invoked, the resource state on the
server remains unchanged.
The term "idempotent" means that, regardless of how many times a particular method is invoked,
the result is the same.
A REST service is based on well-defined verbs, and well-defined rules about what operations are
allowed when using those verbs. These primary verbs are GET, DELETE, PUT, and POST.
The GET verb fetches a resource from the server. GET is categorized as idempotent with no
side-effects.
The DELETE verb removes a resource from the server. DELETE is categorized as idempotent
and obviously has side-effects.
The PUT verb is used to update an existing resource. Depending on the defined interface, this
verb might also create a resource at a specific URL. PUT is categorized as idempotent and has
side-effects.
The POST verb creates a resource, usually in a collection. The server sets the new resource
URL. This verb is also for invoking a handler, “do this complicated process”. The POST verb is
categorized as non-idempotent and usually has side-effects.
Executing an idempotent request more than once yields the same result as would result by
executing it only once. If a client sends a series of idempotent requests, gets disconnected from
the server without getting confirmation of completion, the client can safely retry the series of
idempotent requests without worrying that duplicate records are created. This concept also
applies for deletions. GET, DELETE, and PUT are idempotent since they refer to a specific URL,
and hence a specific resource. The DELETE appears to be non-idempotent, but the result of
duplicate deletes is the same on the server: an absence of the resource on the server.
11

As a parting comment on this slide, note that these REST verbs equate to the HTTP methods
used to invoke them.
12

Slide 12
Example: Employee processing

Resources
• List of employees
• Employee
• Employee salary history
• Employee performance reviews
Operations
• Add employee (create)
• Query for information about employee or employees (read)
• Modify an employee’s information (update)
• Remove an employee (delete)
• Create, read, update, and delete for salary history
 Give an employee a raise = update salary history
• Create, read, update, and delete for performance reviews
Here is an example of a simple service for processing employees. I have defined the resources
that are exposed, and described the operations on those resources I want to perform.
In this example, the primary resource is an employee. Other resources that are needed for each
employee include the employee salary and performance reviews.
The operations that are listed include the creation of new resources, such as creating an
employee. The other CRUD operations (create, read, update, and delete) are listed as well. The
CRUD operations are also supported on the employee salary and employee performance
reviews.
13

Slide 13
Employee REST interface

Resource URI Method Representation Description Status
codes *
Employee /employees GET XML Retrieve list of 200
list (employee list) employees
Employee /employee POST XML Create employee 201

(employee)
" /employee/{id} GET XML Retrieve a single 200, 404
or follow href from list (employee) employee
" " PUT XML Update an 201, 204,

(employee) employee 404
" " DELETE Not applicable Remove an 200, 404
employee
Salary /employee/salary/ POST XML (raise) Give an employee 201, 404
history {emp-id} a raise
Performance /reviews/{emp-id} GET XML (review list) Retrieve an 200, 404
reviews employee’s
reviews
* Because of access control, status codes might include 401 and 403
Here is an example design for the employee processing service.
Each row lists the resource, the URI to access that resource, the HTTP method, the data
representation format, a description of the operation, and the expected HTTP status codes.
I will walk through the second row of the table, matching the values against the REST
requirements.
The second row describes the creation of a new employee. The first value is Employee, a
resource that meets the first REST requirement – application state and functions are divided into
resources. The second column is the URI, /employee, meeting the second REST requirement
that is – every resource is uniquely addressable with a universal syntax. Although this
requirement appears to not be specific, this operation is creating the resource, so you see that
uniqueness in the response. The third column, method, identifies which of the four REST style
services or HTTP methods is used. In this example, the verb POST is used. The fourth column is
the representation, the XML description of the employee.
This specification meets multiple requirements: 1) application state and functions are divided into
resources, the employee is a resource, and 2) all resources are accessible with a uniform,
generic interface, which here is XML.
If it is a POST, the new employee is sent on the HTTP request as POSTed data in XML format.
The fifth column is description, which is a description of the operation. The final column is the
HTTP status codes that are returned from the request. The example on the second row is
expecting a status code of 201, which means “resource created”; the wanted result of a create
operation. The HTTP response also contains POSTed data, which is the ID of the created
employee. With this returned value, a unique URI can be used to reference this resource at a
future time.
The typical status codes that you encounter are:

 200 – OK
 201 – resource created
 204 – no content, successful request but no body is returned
 3XX – redirection
 400 – bad request, malformed syntax of request
 401 – unauthorized, a WWW-Authenticate header is returned with a challenge dialog
14

 403 – forbidden, request is refused by the server

 404 – not found
 500 – internal server error
Note the third row that defines an employee retrieval. The URI specifies /employee/{id}, a specific
URI to request a specific employee. The “id” used here is the value that is returned from the
POST, or creation of the employee resource.
Also, note that the URL column mentions using an “href” from a list. An example is if you retrieved
an employee list, and had each employee on the web page be a link to that specific employee.
This technique implies another part of REST: the use of hyperlinks to connect to resources.
Although this example shows the data format as XML, it certainly can be JSON if appropriate.
Examine the rest of the table at your leisure.
15

Slide 14
Example: REST interaction

Client Server
POST /employee/
["John Smith", "Development"]
HTTP status code 201 [101]
GET /employee/101/
Time
["John Smith", "Development", 101]
DELETE /employee/101/
HTTP status code 200
A UML sequence diagram demonstrates the behavior of objects in a use case by describing the
objects and the messages that are passed. The diagrams are read left to right and descending.
The example here shows the client performing a POST to the URI “/employee/” in which the data
“John Smith” and “Development” is sent. The server returns a status code of 201 – meaning
“resource created”. The new employee ID number 101 is returned. Be aware the responsibility for
setting the HTTP status code and POSTing the new employee ID is on the server application.
Next, a GET is performed on /employee/101 by the client. The server returns the value of “John
Smith”, “Development”, 101, which is the proper information for employee 101.
The final request that is sent by the client is a DELETE /employee/101 in which the server returns
a status code of 200. An HTTP status code of 200 means OK, therefore you can assume that the
server deleted employee 101, which is John Smith in Development.
16

Slide 15
Example: Add employee REST request explained

POST /employee/ HTTP/1.1
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
Accept: */* • The URI specifies the resource that is
Cache-Control: max-age=0 being accessed
Connection: keep-alive • It does not expose the underlying service
implementation
Host: www.example.org
The HTTP method specifies the operation to
be performed
<employee>
<firstName>John</firstName>
<lastName>Smith</lastName>
<department>Development</department>
• The HTTP request body contains
<id></id> information about the resource
</employee> • More types include binary attachments,
such as images
This example shows the syntax of the REST HTTP request being sent from the client to the
server. The POST on the first line is the HTTP method that specifies the operation to be
performed; that is the REST style service. Next to the POST is the URI for the resource,
/employee/. Notice how specifying the resource does not expose the underlying service
implementation. It simply supplies the URI.
The HTTP request body contains information about the resource itself, in this case an XML
representation of the employee data. Not shown in this example is how additional types might
include binary attachments, such as photos.
17

Slide 16
Example: Add employee REST response explained

HTTP/1.1 201 OK
Accept-Ranges: bytes
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Wed, 19 Mar 2008 21:51:16 GMT
Expires: Wed, 19 Mar 2008 21:56:12 GMT
Cache-Control: max-age=0, no-cache
Pragma: no-cache
Date: Wed, 19 Mar 2008 21:56:12 GMT
Connection: keep-alive
• The HTTP status code indicates the
success or failure of the operation
101 • The only information that is
transmitted in the HTTP response is
the actual data itself: the newly
assigned employee ID of 101
Now you can see the server response to the previous client request. The HTTP status code
indicates the success or failure of the operation, in this case a status code of 201, “resource
created”. The HTTP response body contains the newly assigned employee ID of 101.
In fact, a well-written server application would respond with an HTTP Location header that has
the URI to the new resource. And the HTTP body would contain the new resource, not just the
employee ID.
18

Slide 17
Common DataPower REST patterns: Facade

• Provide a REST interface to an existing web service (web service
proxy)
▪ Current web service proxy supports a web services back-end system
▪ Multi-protocol gateway exposes a REST interface to the client, but converts
the REST request to a web services SOAP request
WSP
SOAP SOAP
Web services Existing
service policy
client
MPGW Web services

SOAP
back-end system
REST Request
REST reformatting
client
There are several design patterns that are common when designing REST support within
DataPower: façade, bridged, and REST enrichment.
The first DataPower REST architectural design pattern that I will discuss is Façade. A Façade
design pattern provides a different interface to another interface. In this example, the gateway
currently has a web service proxy (WSP) in production. The web service proxy expects to receive
a SOAP request as input from its web services clients. The desire is to add the REST interface
and continue to support the web service interface, so the current SOAP clients can continue as
usual. The solution is to create a multi-protocol gateway (MPGW) that receives a REST request,
converts it to a SOAP request, and passes the new SOAP request on to the existing WSP. The
WSP response returns to the MPGW, where the MPGW converts the SOAP response to a
RESTful response.
Besides supporting both the web services and REST clients, this approach also allows
enhancements to the WSP to also be used by the requests that come in from the MPGW.
19

Slide 18
Common DataPower REST patterns: Bridge

• Bridge between REST client and back-end web services
▪ Convert REST request to the needed SOAP request format
▪ Can also add other actions as needed (AAA, transforms)
MPGW
REST Request reformatting, SOAP
REST other processing actions
client
Web services
back-end system
Another common DataPower REST architectural design pattern is the Bridge. A Bridge design
pattern separates the abstraction element of a class from its technical implementation. This
pattern provides a cleaner implementation of real-world objects and allows the implementation
details to be changed easily. In the example, the client request is bridged to the web service
functions. In addition to bridging the client to the server, a protocol transformation also occurs.
Here the DataPower gateway is receiving a REST request and reformatting that request into a
SOAP request, then passing the request to the server. The SOAP response is reformatted to a
REST response.
20

Slide 19
Common DataPower REST patterns: REST enrichment

• DataPower service adds capabilities beyond what is in REST back-end
system:
▪ Schema validation
▪ XML threat protection
▪ Authentication, authorization, auditing (AAA)
▪ Service level management (SLM)
▪ Content-based routing
MPGW
REST REST
More message processing
REST
client
REST-based
back-end system
The last DataPower REST pattern that I will discuss is REST enrichment. A REST enrichment
design pattern adds capabilities beyond what is in the REST server or back-end processing. This
pattern allows for a REST client to communicate with a REST server, with additional processing
occurring between. In this example, a multi-protocol gateway is located between the REST client
and the REST server. This multi-protocol gateway might be performing services such as schema
validation, XML or JSON threat protection, AAA, service level management, and content-based
routing.
21

Slide 20
Tools to support REST: Service or protocol handler related

• Front side handler support of HTTP method selection
• Request/response type of non-XML/JSON: MPGW/XMLFW
• Process Messages Whose Body Is Empty: MPGW/XMLFW Advanced

tab
• JSON threat protection
The first discussion is on the DataPower tools to support REST that are configured at the service
level or the protocol handler level. Each of these items will be covered in more detail.
• Front side handler support of HTTP method selection
• Request and response type of non-XML and JSON in a multi-protocol gateway or XML
firewall
• “Process Messages Whose Body Is Empty” option on the multi-protocol gateway and
XML firewall Advanced tab
• Threat protection for JSON
22

Slide 21
Front side handler support of HTTP method selection

• REST design prescribes specific
HTTP methods
• The front side handler wizard

allows selection of specific HTTP
methods
• Note the methods that are selected

by default do not include GET and
DELETE
• REST interfaces require more

attention to the supported HTTP
methods than web services
The definition of an HTTP or HTTPS front side handler includes the ability to specify which HTTP
methods are allowed. This ability has been a choice for a long time, but it has become critical
when fronting RESTful services. You can specify which HTTP methods you want to allow through
the front side handler, dependent on what REST operations you support within the back-end
server. Be aware the default settings for a front side handler do not include GET and DELETE.
23

Slide 22
JSON request and response types

• REST-based bodies might contain XML or non-XML formatted data
• A common structure for REST bodies is JSON
▪ A data structure that is part of JavaScript
• Multi-protocol gateways and XML firewalls provide some automatic
processing of JSON data when specified in the Request Type or
Response Type
REST message bodies might contain data in various data structures, both XML and non-XML.
JSON is a common format in that it integrates easily with JavaScript, is light-weight, and simple.
The request and response types for multi-protocol gateways and XML firewalls can specify
JSON. The effect of specifying JSON is covered later in this unit, along with more detail on JSON.
24

Slide 23
Process bodyless messages

• For typical web services requests, an empty HTTP body causes the
request rule to be bypassed
• REST-based messages might have bodyless requests and responses,
but still require a service policy to run
• If Process Messages Whose Body Is Empty is enabled, the request
rule is executed even if the HTTP body is empty
• Multi-protocol gateway: Advanced tab
• XML firewall: Advanced tab
REST-based messages frequently have bodyless HTTP requests and responses, but the
messages still require a service policy to run. Generally, the default behavior is to bypass the
service policy with an empty body. On the Advanced tab for the multi-protocol gateway and XML
firewall services, you can specify that you want the service policy to execute regardless of an
empty body. This option is indicated by selecting “process messages whose body is empty”.
25

Slide 24
JSON threat protection

• Control some aspects of the dimensions of an input JSON message
▪ Objects > JSON Processing > JSON Settings
• JSON Settings object referenced from a service’s XML Manager
Part of XML threat protection is to limit the size of XML messages. There is a similar capability for
JSON data: JSON Settings. These settings control the character length of the label, the string
value, and the number value. It also sets the maximum nesting depth of elements, and the total
message size.
Messages that violate these limits are rejected.
Although JSON Settings relate to JSON data, it is specified as part of the XML Manager for the
service.
26

Slide 25
Tools to support REST: Service policy-related

• Matching rule: HTTP method (GET, PUT, POST, DELETE, HEAD)
• Method rewrite action: Change HTTP method
• Convert query parameters action
• XSL and GatewayScript read/write access to HTTP method and HTTP
status code
• JSON request type auto-converted to JSONx
• Convert query parameters action can convert JSON to JSONx
• Jsonx2json.xsl stylesheet to transform JSONx to JSON
• Jsonx.xsd to validate JSONx
• Validate action supports JSON schemas
• Transform action adds XQuery/JSONiq processing
• GatewayScript action to support JavaScript processing
• Actions that allow http:// access: Fetch, Results, Results Async,
Log
Some of the DataPower tools to support REST are used within a service policy. These
capabilities are:
• A matching rule for the Match action allows matching on the HTTP method
• Method rewrite action to change the HTTP method
• Convert query parameters action
• XSL and GatewayScript read/write access to the HTTP method and the HTTP status
code
• JSON request and response type auto-converted to JSONx
• Convert query parameters action can convert JSON to JSONx
• jsonx2json style sheet to transform JSONx to JSON
• jsonx schema to validate JSONx
• Validate action supports checking JSON schemas
• Transform action adds XQuery and JSONiq processing
• Since the Fetch, Results, Results asynchronous, and Log actions can specify HTTP
access, they can use a RESTful interface.
These items are covered in the following slides.
27

Slide 26
Matching Rule on HTTP methods

• A Match action’s Matching Rule can be configured for each of the
HTTP methods
▪ Makes it easy to configure a processing rule that handles a specific HTTP
method
The Matching Rule that is attached to a Match action is enhanced to look at the HTTP method on
the incoming message. You can specify the basic REST methods of DELETE, GET, HEAD,
POST, and PUT. “Default” indicates either a GET or POST successfully matches. The HTTP
method of HEAD is like a GET request, but no message body is returned.
This type of matching rule supports creating separate processing rules for each type of HTTP
method.
28

Slide 27
Changing the HTTP method in the processing rule

• SOAP-based web services use the HTTP POST method, regardless of
the nature of the request
• Depending on the nature of the request, a RESTful request uses the
associated HTTP method
• When bridging between SOAP web services and REST web services,
the HTTP method might need to be changed
• The Method Rewrite action (under the Advanced action) specifies a
specific HTTP method
▪ For example, the original REST GET request gets converted to a SOAP
POST request
SOAP-based web services use the HTTP POST method, regardless of the nature of the request.
The HTTP method on a RESTful request depends on the specific operation, so the method
varies. When bridging between SOAP web services and REST web services, the HTTP method
might need to be changed.
The Method Rewrite action, which is selected from the Advanced action, lets you specify which
HTTP method you want associated with a processed message.
A common situation is a RESTful GET, which obviously uses a GET HTTP method. The SOAP
request that is being passed to a SOAP web service expects an HTTP POST. The Method
Rewrite action can be used to change the incoming HTTP method to what is needed on the back
end.
29

Slide 28
Convert Query Params to XML action

• Original purpose was to converts non-XML (HTTP POST, HTML form,
or URI parameters) into an equivalent XML message
▪ For a service to use this action, the request type for that service must be set
to XML
• Can also be used to convert JSON to JSONx
The Convert Query Params to XML action has been available for a long time. Its original purpose
was to convert non-XML data, such as HTML form data and URI request parameters, into an
equivalent XML structure.
This capability is helpful for REST requests as well. Many of the details of a REST request are
contained within the URI. It is common to need that information to process the message within
the service policy. This action parses the URI parameters on the HTTP request, and produces an
XML node that you can process in a following style sheet. This same action can be used to parse
other name-value pairs such as POSTed data, and HTML form data. The parsing can accept
different types of encoding, of which “URL encoding” and “JSON” are of importance in this
RESTful discussion.
One caution is that the request type for the service must be set to “XML” to use this action in this
way.
30

Slide 29
Convert Query Params to XML action: Query parameters

example
• Example cURL command
curl -G
"http://dphost:port/EastAddressSearch/people/
?firstName=Victor&lastName=Collins&title=Mr"
• Is converted to the following XML:

<request>
<url>
/EastAddressSearch/people/?firstName=Victor&lastName=Collins&a
mp;title=Mr
</url>
<base-url>/EastAddressSearch/people/</base-url>
<args src="url">
<arg name="firstName">Victor</arg>
<arg name="lastName">Collins</arg>
<arg name="title">Mr</arg>
</args>
</request>
This slide shows the results of a Convert Query Params to XML action. At the top, you see a
cURL command. The “-G” in the command indicates that you want this command to use an HTTP
GET method, rather than the default POST. The URI contains the search parameters for the
person retrieval.
On the lower part of the slide is the result of the Convert Query Params to XML action, that uses
the URL encoding. The resulting XML node is easy to traverse in a style sheet.
31

Slide 30
Programmatic access to the HTTP method

• XSLT extension function to retrieve which HTTP method is invoked in
the HTTP request
▪ The dp:http-request-method() extension function returns a string
that contains the HTTP method
• A service variable, var://service/protocol-method, can be

used to read or write the HTTP method
▪ XSL:
<xsl:variable name= "HTTPmethod"
select="dp:variable('var://service/protocol-method')"
/>
or
<dp:set-variable name="'var://service/protocol-method'"
value="'GET'" />
▪ GatewayScript:
var serviceVars = require ( 'service-metadata' );
var HTTPmethod = serviceVars.protocolMethod;
or
serviceVars.protocolMethod = 'GET';
Reading and setting the HTTP method is important in REST applications. I have already
mentioned the Method Rewrite action as a way to set an HTTP method value. You can also read
and set the HTTP method within a style sheet or GatewayScript.
The http-request-method() extension function returns a string that contains the HTTP method
indicated in the request. This is a style sheet-only function.
The service variable protocol-method can be used to read or set the HTTP method. You can use
the set-variable extension element in a style sheet to set the HTTP method, or you can use a Set
Variable action as well. If you want to read the value, you can use dp:variable extension function.
You can read or write the same protocol-method service variable in GatewayScript.
32

Slide 31
Programmatic access to the HTTP status code

• You can retrieve the HTTP status code from the request
▪ XSL: The dp:http-response-header('x-dp-response-code')
extension element returns a string that contains the HTTP status code
<xsl:variable name="responseCode" select="dp:http-
response-header('x-dp-response-code')" />
▪ GatewayScript:
var hm = require('header-metadata');
var currentSC = hm.current.statusCode;
• You can also set it in a similar fashion

▪ XSL:
<dp:set-http-response-header name="'x-dp-response-
code'" value="'204'" />
▪ GatewayScript:
hm.response.statusCode = "204";
• The status code is read-only in the original context, and read/write

in the current and response contexts
An important part of the RESTful interface for a service is the significance of specific HTTP status
codes that are returned on the response. If you are bridging between a REST client and a SOAP
back end, you might need to control the returned status code.
In a style sheet, you can use the dp:http-response-header(‘x-dp-response-code’) extension

element to retrieve the status code. An example of using that element within a style sheet
variable is shown on the slide.
The “current” status code can also be retrieved in a GatewayScript.
You can use the setter version of that extension element to set a specific value for the HTTP
status code. Another example is shown that sets the status code to 204.
You can set the status code in a GatewayScript in a similar fashion.
For GatewayScript, the original value of a header that comes into the rule is in the “original”
context, and is read-only.
The value of the header within the GatewayScript action is in the “current” context, and is
read/write.
The value of the header within the GatewayScript action that is associated with the response is in
the “response” context, and is also read/write.
In the example code, notice that the setting of the status code to 204 is in the “response” context
of the header.
33

Slide 32
JSON
• JavaScript Object Notation
▪ Subset of JavaScript
▪ Minimal
▪ Lightweight
▪ Text-based
▪ Language-independent
▪ Easy to parse
▪ Not a document format
• JSON is a simple, common representation of data that can be used for

communication between servers and browser clients, communication
between peers, and language-independent data interchange
• For more information, see: http://json.org
JSON is an acronym that stands for JavaScript Object Notation, and is a subset of JavaScript
itself. It is fairly simplistic and minimal as compared to other formats such as XML. It is a light-
weight approach to define, structure, and transmit data. As you have seen, and will further
experience, JSON is text-based. It is a standard that works with any language. Since it is name-
value pairs and simple structures, it is easy to parse. But remember that it is a data format, not a
document format.
In a one sentence definition, JSON is a simple, common representation of data that can be used
for communication between servers and browser clients, communication between peers, and
language independent data interchange. It is most commonly used between browser clients and
the back-end services, usually as a light-weight replacement for XML.
JSON is described at http://json.org.
34

Slide 33
JSON data types
"Hello world!\n" A string is a sequence of zero or more Unicode characters
-1.4719e7 A number includes an integer part that can be prefixed with a

sign and followed by a fraction or an exponent
{"name":"John"} An object is an unordered collection of zero or more name-

value pairs
["a","b","c"] An array is an ordered sequence of zero or more values
true A boolean is a literal value of either true or false
null The keyword null represents a null value

JSON values must be an object, array, number, or string, or one of the three literal names: false,
true, or null.
A string is a sequence of zero or more Unicode characters.

A number includes an integer part that can be prefixed with a sign and optionally followed by a
fraction or exponent.
An object is an unordered collection of zero or more name-value pairs.
An array is an ordered sequence of zero or more values.
A boolean is a literal value of either true or false.
The keyword null represents a null value.
As you can see, JSON data typing is minimal, and text-based.
35

Slide 34
JSON version of an XML structure

• XML • JSON
<Person> {
<details> "Person":{
<city>Cleveland</city> "details":{
<state>OH</state> "city":"Cleveland",
<street>3661 Lincoln "state":"OH",
Ave</street> "street":"3661
<zipCode>44111</zipCode> Lincoln Ave",
</details> "zipcode":44111
<name> },
<firstName>Sarah</firstName> "name":{
<lastName>Chan</lastName> "firstname":"Sarah",
<title>Mrs</title> "lastname":"Chan",
</name> "title":"Mrs"
</Person> }
}
}
This slide shows an example of a JSON version of an XML node. The element names can
become the name part of the name-value pairing common in JSON.
The city, state, street, firstname, lastname, and title are JSON strings.
The zipcode is a JSON number.
Person, details, and name are JSON objects.
36

Slide 35
JSONx
• Is an XML encoding of a JSON data structure
• Used by several IBM products
• Is an internet Draft in the IETF
▪ https://tools.ietf.org/html/draft-rsalz-jsonx-00
• The root element is a <json:object> or <json:array> element
• Child elements are elements that are related to the JSON types
▪ <json:array>
▪ <json:boolean>
▪ <json:string>
▪ <json:object>
▪ <json:number>
▪ <json:array>
▪ <json:null>
JSONx has been mentioned several times; so what is it? In short, JSONx is an XML encoding of
a JSON data structure. It was developed by IBM, and is used in several IBM products. But it is
not limited to IBM only, it has been submitted to IETF as an internet draft. You can review it at the
URL on the slide.
The elements align with the JSON data types. The root element must be a <json:object> or
<json:array> element. The child elements can be any of the elements that relate to the JSON
types.
37

Slide 36
JSONx version of JSON data structure

• JSON • JSONx
{ <json:object name="Person">
"Person":{ <json:object name="details">
"details":{ <json:string
name="city">Cleveland</json:string>
"city":"Cleveland", <json:string name="state">OH</json:string>
"state":"OH", <json:string name="street">
"street":"36 36 Lincoln Ave</json:string>
Lincoln Ave",
"zipcode":44111 <json:number
name="zipcode">44111</json:number>
},
</json:object>
"name":{
<json:object name="name">
"firstname":"Sarah", <json:string
name="firstName">Sarah</json:string>
"lastname":"Chan", <json:string
"title":"Mrs" name="lastName">Chan</json:string>
} <json:string name="title">Mrs</json:string>
} </json:object>
} </json:object>
On the left is the JSON structure for the Person object that you have seen on the last few slides.
On the right, you can see the JSONx representation. First note that the JSONx result is a valid
XML structure. The individual elements for city, state, street, and zipcode are enclosed within the
“details” element. The elements for firstname, lastname, and title are enclosed within the “name”
element. Both the details and name elements are enclosed within the “Person” element.
38

Slide 37
Handling JSON in the request body

• If Request Type is set as non-XML
▪ Use a stylesheet or GatewayScript in the processing policy to manipulate as
needed
▪ Can use a Convert Query Parameters action with a JSON input encoding to
convert the JSON to JSONx
• If Request Type is set as JSON

▪ The JSON input is validated as well-formed JSON
▪ The service automatically converts the JSON body to JSONx
▪ The JSONx version of the body is placed in the _JSONASJSONX context,
and is available in the processing policy for manipulation
▪ The INPUT context is still valid, and contains the original JSON body
When you receive JSON input on the request, you can set the request type as either non-XML, or
as JSON.
As non-XML input, you can easily transform the JSON into anything you want since the JSON is
text. Another common choice is to use a Convert Query Params into XML action, with a JSON
input encoding. This action converts the JSON to JSONx. The JSONx can then be transformed
by a style sheet into any XML structure needed.
If you choose JSON as the request type, the gateway automatically performs some operations for
you. The JSON input is validated as well-formed JSON. After that, the JSON is converted to
JSONx, and the JSONx is placed in the _JSONASJSONX context. That context can be accessed
in the service policy for any further processing. The original JSON input remains in the INPUT
context.
39

Slide 38
Converting JSON to XML

• Use Convert Query Parameters action with JSON default encoding
▪ Output is JSONx
▪ Simplest approach
▪ Example follows
• Use a stylesheet or GatewayScript

▪ If output of Convert Query Parameters action does not meet needs
On the request side, you might need to convert the incoming JSON to a SOAP or XML message.
One approach is to use a Convert Query Params to XML action. In a previous slide, this action
was used to convert non-XML input from the URL request parameters to an XML structure. In this
case, the action converts the JSON structure from the action’s input context to a JSONx data
structure. An example is on the following slide.
If the automatic conversion that is performed by the Convert Query Params to XML action is not
sufficient for your needs, you can use a style sheet or GatewayScript to manually convert the
JSON structure to any XML structure.
40

Slide 39
Convert Query Params to XML action: JSON example (1 of 2)

• Input conversion map of Convert Query Params to XML action
specifies JSON encoding
• person.json input: {"Person":

{"details":
{"city":"Cleveland",
"state":"OH",
"street":"3661LincolnAve",
"zipcode":44111},
"name":
{"firstname":"Sarah",
"lastname":"Chan",
"title":"Mrs"}
}
}
This slide shows a sample person.json structure that is input to a Convert Query Params to XML
action. The action specifies JSON encoding, rather than URL encoding.
41

Slide 40
Convert Query Params to XML action: JSON example (2 of 2)

• Example cURL command
curl http://172.16.78.12:11999 --data-binary @person.json
• JSONx XML output from JSON input:
<json:object ... >
<json:object name="Person">
<json:object name="details">
<json:string name="city">Cleveland</json:string>
<json:string name="state">OH</json:string>
<json:string name="street">3661LincolnAve</json:string>
<json:number name="zipcode">44111</json:number>
</json:object>
<json:object name="name">
<json:string name="firstname">Sarah</json:string>
<json:string name="lastname">Chan</json:string>
<json:string name="title">Mrs</json:string>
</json:object>
</json:object>
</json:object>
At the top is the cURL command to send the person.json file as the HTTP body to a DataPower
service that contains the Convert Query Params to XML action.
The lower portion of the slide shows the resulting JSONx structure that is the output of that
action.
42

Slide 41
Converting XML to JSON

Take advantage of JSONx and a supplied stylesheet
• Use a custom stylesheet to parse the input XML structure and build a
JSONx representation
• Use the store:///jsonx2json.xsl to convert the JSONx to a
JSON data structure
▪ This technique performs the reverse of what the JSON request type and
_JSONASJSONX context does
XSL ...
<json:object name="details">
<json:string name="state"> {"details":{
<xsl:value-of select="details/state" /> "state":"OH",
</json:string> "zipcode":44111
<json:number name="zipcode"> }
<xsl:value-of select="details/zipCode" }
/>
</json:number>
...
• Create the JSON directly from the XML input with a stylesheet or
GatewayScript
On the response side, you might need to convert the SOAP or XML message to a JSON
structure.
One approach is to take advantage of the supplied jsonx2json style sheet in the store: directory.
In this approach, you transform the XML message into JSONx via your own style sheet. This
transformation is fairly simple as you are going from XML to XML. You then take the resulting
JSONx structure and run it through the jsonx2json style sheet. This style sheet converts the
JSONx to valid JSON. You are in effect doing the reverse of what the JSON request type and
_JSONASJSONX context do on the request.
Another approach is to use a style sheet or GatewayScript to directly transform the XML message
into the textual JSON data structure.
43

Slide 42
Validate action for JSON

Perform schema-based validation of JSON documents:
• Validate Document
via JSON Schema
URL
▪ Specifies a schema
URL of a JSON
schema file
▪ Validates the input
document against
the specified JSON
schema
▪ Similar to validating
an XML document
against an XSD or
WSDL
▪ Supports Draft 4 of the IETF specification:
http://tools.ietf.org/html/draft-zyp-json-schema-04
The Validate action can be used to validate the schema of JSON structures. The JSON schema
URL can reference either a local or remote file.
The expected file type for a JSON schema is JSV or JSON.
DataPower supports draft 4 of the IETF JSON schema specification.
44

Slide 43
Example JSON and a JSON schema

• JSON • JSON schema
{ {"type":"object",
"Person":{ "$schema": "http://json-schema.org/
draft-04/schema",
"details":{ "properties":{
"city":"Cleveland", "Person": {
"state":"OH", "type":"object",
"properties":{
"street":"36 Lincoln Ave",
"details": {
"zipcode":44111 "type":"object",
}, "properties":{
"city": { "type":"string" },
"state": { "type":"string" },
"name":{
"street": { "type":"string" },
"firstname":"Sarah", "zipcode": { "type":"number" }
"lastname":"Chan", }
"title":"Mrs" },
"name": {
} "type":"object",
}
(and so on)
}
On the right is a JSON schema that describes a Person object that contains a details object and a
name object. These contained objects describe JSON elements within them. The schema does
not show constraints like required items, numeric ranges, and other constraints.
On the left is a JSON structure that conforms to the schema.
45

Slide 44
Transform action that uses XQuery (JSON and XML)

Use XQuery expressions to manipulate JSON and XML documents
• Transform with a processing control file, if specified
▪ Identifies the XQuery transform file that is referenced in the Transform File field
• XQuery is a query
language for XML
data (like SQL for
relational data)
▪ DataPower V6.0.0
added the support for
the JSONiq extension
(JSON support)
• Input Language:
▪ JSON
▪ XML
▪ XSD
• Transform Language:
▪ XQuery
▪ None (identity)
One of the options for the Transform action supports XQuery as the transformation language,
rather than XSLT.
XQuery is a language that is designed to query XML data, much like SQL is used to query
relational data. DataPower includes the JSONiq extension to XQuery. This extension adds
support for JSON-structured data to XQuery.
The Input Language choice indicates whether the input document is JSON or XML. The third
option of XSD indicates that the input document is XML, but it also displays another entry field
that accepts an XML schema file location. This schema is used to type the data (integer, number,
text, for example) for the XQuery processing, but it does not perform any validation against the
schema. To do that, you must use a Validate action.
The Transform Language choice indicates the language of the transformation file. To perform the
XQuery processing, the choice is ”XQuery”. The choice of “None” performs an identity transform
only.
46

Slide 45
XQuery/JSONiq example
• JSON input message
[{"firstname":"John", "lastname":"Smith", "order":"20223", "price":23.95},
{"firstname":"Alice", "lastname":"Brown", "order":"54321", "price":199.95},
{"firstname":"John", "lastname":"Smith", "order":"23420", "price":104.95},
{"firstname":"Bob", "lastname":"Green", "order":"90231", "price":300.00},
{"firstname":"Scott", "lastname":"Jones", "order":"54321", "price":99.95},
{"firstname":"Jim", "lastname":"Lee", "order":"89820", "price":46.50}]
• From the array, return the name of any customers who have an order
value of $100 or more, ordered by lastname
declare option jsoniq-version "0.4.42";
for $x in jn:members(.)
where $x("price") >= 100.00
order by $x("lastname")
return concat($x("firstname"), ' ', $x("lastname"), '
')
Alice Brown
Output message Bob Green
Scott Jones
John Smith
This example shows a JSON input message that is sent to a service.
The next section of code shows an XQuery statement in a Transform action. This query returns
the names of any customers in the input array who have an order value of $100 or more, ordered
by last name. Notice that the statement declares the JSONiq requirement.
The last box shows the output message from the query execution.
47

Slide 46
GatewayScript action that uses JavaScript

• Provides an encapsulated and secure JavaScript environment
 ECMAScript 2015 (ES6) language specification plus block scoping, strict mode,
no eval() function or compilation from strings, read-only access
to only certain directories in
the file system
 CommonJS Module/1.0
specification
• Access to DataPower
variables, contexts, objects
similar to XSL
 Some objects are provided by
default, such as the session
object
 Some objects need a require
function, such as
header-metadata
 urlopen.open() to
communicate with other
servers, and read access to
local: and store:
GatewayScript is an ECMAScript 2015, or ES6, language with a few additions, such as block
scoping, and strict mode.
Although there is no gateway-wide eval() function, you can enable the eval() function temporarily
within a single transaction. There are other restrictions and additions. See the “GatewayScript
programs” section of the IBM Knowledge Center for more details.
You get access to DataPower variables, contexts, and objects in the same way that you do with
XSL. To access some objects you use a require() function, while others, such as the session
object, are available by default.
48

Slide 47
Sample GatewayScript: JSON input to SOAP output

session.input.readAsJSON(function(error,json) {
if (error) {session.output.write("oops error " +
JSON.stringify(error.toString()));
} else {
debugger;
var refNo = json.refNumber;
var lastName = json.lastName;
console.info("Request for %s with reference %i", lastName, refNo);
session.output.write(
"<soapenv:Envelope
xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" "
+ "xmlns:fly=\"http://www.ibm.com/datapower/FLY/BaggageService/\">"
+ "<soapenv:Header/><soapenv:Body>"
+ "<fly:BaggageStatusRequest>"
+ "<fly:refNumber>" + refNo + "</fly:refNumber>"
+ "<fly:lastName>" + lastName + "</fly:lastName>"
+ "</fly:BaggageStatusRequest>"
+ "</soapenv:Body></soapenv:Envelope>"
); } });
This is a sample GatewayScript program to convert JSON input to SOAP output.

“session.input” identifies the input context for this GatewayScript action.
The “readAsJSON” method reads the context and places it into an object named “json”. If there is
an error on the read operation, an error message is written to the output context.
“debugger” enables the CLI debugger capability.
The input “json” object is read to retrieve the reference number and last name of the passenger.
Those values are placed into variables that are used later in the script.
Information on the request is written to the system log at the “info” level.
The SOAP message is literally constructed. The reference number and last name are retrieved
and placed as contents within the message. The SOAP message is written to the output context
of the action.
The typical spacing of the code is compressed to fit the slide.
49

Slide 48
Bridging REST and SOAP: Sample service policy #1
• In the request:
▪ Match on HTTP method = GET
▪ Convert URI parameters to an XML structure
▪ Build the SOAP request
▪ Set the HTTP method to POST
▪ Set the back-end URL (to target web service)
▪ Set the back-end URI (to target web service)
• In the response:
▪ Match on all URLs
▪ Transform the SOAP response to a JSONx structure
▪ Transform the JSONx to JSON by using jsonx2json.xsl
This is the first of two sample service policies that deal with REST.
To gather some of the concepts together, this slide examines a sample service policy that takes a
REST request and converts it to a SOAP request for back-end servicing. In this case, it is a GET,
or read request. The resulting response is converted from a SOAP response to a REST
response.
For the REST request:

1. A Match action is set to trigger on an HTTP GET method.
2. A Convert Query Params into XML action generates an XML representation of the query
parameters for the REST request.
3. A transform is used to build the SOAP request, by using the converted query parameters.
4. The GET request arrives as an HTTP GET. The back-end web service is looking for a
POST. A Method Rewrite action is used to perform the HTTP method switch.
5. Depending on the nature of the service policy, the back-end URL can be specified as a
static back end or it can be set via Set Variable action.
6. The incoming URI parameters are not what the back end expects. Use another Set
Variable action to specify the correct URI.
For the SOAP response:

1. Create a Match action that accepts all URLs from the back end. Depending on the nature
of the web service, you might specify additional matching rules to differentiate the
various responses.
2. Use a style sheet to transform the SOAP response to a JSONx structure.
3. Use the supplied jsonx2json style sheet to convert the JSONx to the JSON structure the
REST client expects.
For simplicity, this example does not show any error handling, or setting of HTTP status codes.
50

Slide 49
Bridging REST and SOAP: Sample service policy #2
• In the request:
▪ Match on HTTP method = GET
▪ Use GatewayScript to convert URI parameters to an XML structure
▪ Normalize the XML with an identity transform
▪ Set the HTTP method to POST
▪ Set the back-end URI (to target web service)
• In the response:
▪ Use XPath matching rule to match on the specific response
▪ Use XQuery and JSONiq to convert the SOAP response to a JSON
response
This second sample is similar to the first, but it uses a GatewayScript approach.
On the request:
1. A Match action is set to trigger on an HTTP GET method.
2. A GatewayScript action uses service variables to retrieve the URI parameters and
construct the appropriate SOAP request.
3. The SOAP request is normalized with an identity transform.
4. The HTTP method is changed to POST.
5. The back-end URI is set in a service variable.
The response rule converts the SOAP response into a REST JSON response by using an
XQuery transform.
51

Slide 50
Unit summary
• Add support to DataPower services to support REST applications
• Describe how to integrate with systems by using RESTful services
• Use the DataPower gateway to proxy a RESTful service
52


Slide 1: ZE752 Unit 1 Transcript

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Slide 1: ZE752 Unit 1 Transcript

Uploaded by

Copyright:

Available Formats

ZE752 Unit 1 Transcript

REST and JSON support for

© Copyright IBM Corporation 2016

© Copyright IBM Corporation 2016

How to check online for course material updates

1. Enter this URL in your browser:

6. To save the file to your computer, click the

© Copyright IBM Corporation 2016

© Copyright IBM Corporation 2016

Alternatives to SOAP-based web services

Service-oriented architecture (SOA) focuses on interoperability between computer-to-computer

© Copyright IBM Corporation 2016

Web SOA (Web 2.0) versus Enterprise SOA

© Copyright IBM Corporation 2016

Web SOA protocols and standards

Data format standards and techniques

REST is one of the primary subjects of this unit.

© Copyright IBM Corporation 2016

Growth of mobile clients

Different types of interfaces

Mobile clients usually use a REST and JSON interface.

© Copyright IBM Corporation 2016

DataPower as the reverse proxy for Web 2.0 and mobile

XML and web services

© Copyright IBM Corporation 2016

Securing the reverse proxy with IBM Security Access

Mobile and web

REST Access Manager

© Copyright IBM Corporation 2016

Representational State Transfer (REST) is a style of software architecture for distributed

© Copyright IBM Corporation 2016

© Copyright IBM Corporation 2016

© Copyright IBM Corporation 2016

Example: Employee processing

© Copyright IBM Corporation 2016

Employee REST interface

Employee /employee POST XML Create employee 201

" " PUT XML Update an 201, 204,

Here is an example design for the employee processing service.

The typical status codes that you encounter are:

© Copyright IBM Corporation 2016

 403 – forbidden, request is refused by the server

© Copyright IBM Corporation 2016

Example: REST interaction

HTTP status code 201 [101]

["John Smith", "Development", 101]

HTTP status code 200

© Copyright IBM Corporation 2016

Example: Add employee REST request explained

© Copyright IBM Corporation 2016

Example: Add employee REST response explained

© Copyright IBM Corporation 2016

Common DataPower REST patterns: Facade

MPGW Web services

© Copyright IBM Corporation 2016

Common DataPower REST patterns: Bridge

© Copyright IBM Corporation 2016

Common DataPower REST patterns: REST enrichment

© Copyright IBM Corporation 2016

Tools to support REST: Service or protocol handler related

• Request/response type of non-XML/JSON: MPGW/XMLFW

• Process Messages Whose Body Is Empty: MPGW/XMLFW Advanced

• JSON threat protection