The document provides information about Mule Integration Workshop sessions on REST web services and Anypoint Platforms. It includes sections on basic web services styles, Mule and web services, differences between WS-* and REST, web service security in Mule, the Jersey framework for REST, and consuming RESTful web services in Mule. The workshop will cover topics like connecting applications with REST and Anypoint Platform, connecting SaaS applications, and building and managing APIs with Anypoint Platform for APIs.

1. Mule Integration Workshop
REST Webservices

2. •Rapidly connect any application, anywhere
•Anypoint Platform helps companies prepare for the future
with a next-generation SOA platform that connects on-
premises systems and the cloud.
•Mule ESB, CloudHub, Mule Studio, Mule Enterprise
Management, Anypoint Connectors
Anypoint
Platform
for SOA
•Connect SaaS with any application, anywhere
•Anypoint Platform helps companies connect SaaS applications
to each other and the enterprise, in the cloud and on-
premises.
•CloudHub, Mule ESB, Mule Studio, CloudHub Insight,
Anypoint Connectors
Anypoint
Platform
for SaaS
•All you need to connect any app, any device and any API
•With the Anypoint Platform for APIs, you can build new APIs,
design new interfaces for existing APIs and more efficiently
manage all your APIs using a single platform.
•API Portal, API Manager, Mule Studio, Mule ESB, CloudHub
Anypoint
Platform
for API
MuleSoft Anypoint Platforms
1

3. Chapters
Schedule
Filter Types
Basic Webservices – Web Service Style
Mule and Web Services
WS-* vs REST
Web Service Security in Mule
Jersey Framework
Jersey Framework - REST
Jersey Framework – JAX - RS
Deploying the JAX-RS service in Mule
Consuming RESTful Web Services in Mule

4. Basic Webservices – Web Service Style
 A web service is a service which uses a set of web standards (e.g., HTTP, SOAP,
JSON, etc...,) to expose its interface to its clients and interact with them. Two main
web service flavors are:
 WS-*
 RESTful
 With WS-* web services, a client application utilize XML messages using the SOAP
standard. Such a request is recognized by the web service and returns a response
to the client. If a client does not know what operations a web service provides,
then the WSDL for the service can be queried to see what operations are
supported before the request is made.
 WS-* services can be constructed using various technologies – Axis, CXF and .NET
being the most popular – and clients can also invoke these services using any of
these technologies. Mule enables the use of web services by providing an Axis and
a CXF transport.
 RESTful services on the other hand are invoked using a URI and unlike WS-* are
not restricted to use SOAP XML payloads. RESTful services make use

5. Basic Webservices – Web Service Style (Contd)
of the HTTP APIs to expose different services, unlike WS-* which uses a
WSDL to define the API.
 Both of these web service styles are typically synchronous, client sends a
request and it expects a response.
Mule and Web Services

6. Mule and Web Services
 The diagram here shows how Mule can interact with web services. On the left,
we can see that a third-party item (such as an application) is making a web
service call, which refers to a service that is hosted in Mule. This web service
call is nothing more than an inbound endpoint for the service. By using
inbound web service endpoints, Mule can host web services that are
accessible to any other application.
 On the right side, we can see that a service in Mule is making a web service
call to a third-party item. This web service call is nothing more than an
outbound endpoint for the service. By using outbound web service endpoints,
Mule can connect to web services hosted by any other application.

7. WS-* vs REST
 The two different web services cannot be compared directly. Although both
help to build web services, WS-* is a set of technology standards while REST is
an architectural style. However, here we list some major differences:
• Message format:
o WS-* requires use of XML (transmission of binary data requires extra
work)
o HTTP resources can be of any type
• Transport Neutrality:
o SOAP is transport neutral (e.g., use JMS to support transactions)
o REST services are tied to HTTP
• Reliability:
o WS-* uses WS-ReliableMessaging
o Rest uses idempotent operations

8. Web Service Security in Mule
 Since REST is dependent on the HTTP transport, it is very simple to use the
security layer of the HTTP to secure a REST service. These include
• HTTPS Transport Level Security
o Authentication using Certs
o Confidentiality (Encryption)
o Integrity
• HTTP Basic Authentication using Spring
 When SOAP services are being hosted on HTTP, which is in most cases, the
above options are also available. However, since SOAP services are aimed at
being transport neutral, they also provide a set of standards covered by the
WS-* umbrella, some of which are:
• XML Encryption
• XML Signature
 With SOAP services, Mule also offers SAML integration for single sign-on.

9. Jersey Framework
 In Mule, support for REST is provided through the Jersey module, which
leverages the JAX-RS API to produce and process REST messages.
 Using Jersey, the message’s payload is not restricted to any particular
structure. Therefore, payloads such as text, JSON, XML, and binary may be
used. However, this module may only be used in conjunction with the HTTP
transport.
REST
 REST is an architectural style for accessing information on the web.
 In the REST architectural style, information on the server side is considered a
resource, which may be accessed in a uniform way, using web URIs (Uniform
Resource Identifiers) and HTTP.
 Since REST uses HTTP as the communication protocol, the REST style is
constrained to a stateless client/server architecture.

10. Jersey Framework - REST
 Important HTTP methods:
 GET (gets a resource, similar to WWW)
 PUT (updates a resource, not commonly found in WWW)
 POST (creates a new entry, similar to WWW)
 DELETE (removes a resource, not commonly found in WWW)
JAX-RS
 JAX-RS uses annotations to build RESTful web services. Annotations, along
with the classes and interfaces provided by the JAX-RS API, allow to expose
simple POJOs as web resources.
 There are a number of JAX-RS implementations including Jersey (which is what
Mule uses to provide REST support), Restlet and RESTEasy.

11. Jersey Framework – JAX - RS
 Some JAX-RS Annotations include:
 @Path: Specify path of resource (the resource’s URI)
 @GET/@PUT/@POST/@DELETE : Specify HTTP request type
 @Produces: Specify the MIME media types of representations a resource
can produce and send back to the client.
 @Consumes: Specify the MIME media types of representations a resource
can consume that were sent by the client.
 @PathParam: used to extract a path parameter from the path component
of the request URL.
 @QueryParam: used to extract query parameters from the Query
component of the request URL.
 @HeaderParam: extracts information from the HTTP headers.

12. Jersey Framework – JAX - RS(Contd)
Eg: Example for how to use these annotations to annotate POJO to be configured later as a REST service.
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
@Path("/")
public class HelloRestComponent {
@GET
@Produces("text/plain")
@Path("/greeting/{name}")
public String greet(@PathParam("name") String input){ return "Hello "+ input; }
}
In the above Java class, we are telling our JAX-RS server that this component should be hosted on the resource URI
“/”, using the @Path annotation, hence if the server is listening on http://localhost:8080/hello, then our
HelloRestComponent will be listening on http://localhost:8080/hello/. The greet() method is annotated as a GET
method, and with the @Path having a value of /greeting/{name}. This means that when the client asks for the
resource http://localhost:8080/hello/greeting/mule, the greet() method will be invoked passing the mule
parameter from the URI into the input parameter on the greet() method. The mule parameter is injected in the
input parameter through the @PathParam annotation.

13. Deploying the JAX-RS service in Mule
Deploying the JAX-RS service in Mule
 Exposing a REST service in Mule is as easy as configuring an HTTP inbound
endpoint followed by a Jersey resource element containing the component as
shown here:
Eg:
<flow name="RestHelloFlow">
<http:inbound-endpoint address="http://localhost:8080/hello" />
<jersey:resources> <component class="com...HelloRestComponent" /> </jersey:resources>
</flow>
 If the flow is not going to be followed by other message processors following
the Jersey resource, then use a shortcut configuration to configure your
service:
Eg:
<simple-service name="RestHelloService" component-class="com...HelloRestComponent" type="jax-rs" address="
http://localhost:8080/hello"/>

14. Consuming RESTful Web Services in Mule
Consuming RESTful Web Services in Mule
 The example below shows how to consume a RESTful web service in Mule.
Eg:
<flow name="...">
<http:outbound-endpoint exchange-pattern="request-response" host="localhost"
path="resources/greeting/#[message:payload]" port="8080" method="GET">
</http:outbound-endpoint>
...
</flow>
An HTTP outbound endpoint is configured. The path the greeting method is formed and the parameter is extracted
from the message payload, thus the endpoint is generated dynamically. The exchange pattern used is ‘request-
response’, as the web service is synchronous. In this case the ‘GET’ method is used.

15. Thank you