+ All Categories
Home > Technology > Rest web services

Rest web services

Date post: 14-Apr-2017
Category:
Upload: sathyaraj-anand
View: 79 times
Download: 0 times
Share this document with a friend
15
Mule Integration Workshop REST Webservices
Transcript
Page 1: Rest web services

Mule Integration Workshop REST Webservices

Page 2: Rest web services

• 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

2

Page 3: Rest web services

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

Page 4: Rest web services

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

Page 5: Rest web services

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

Page 6: Rest web services

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.

Page 7: Rest web services

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

Page 8: Rest web services

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 Certso 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.

Page 9: Rest web services

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.

Page 10: Rest web services

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.

Page 11: Rest web services

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.

Page 12: Rest web services

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.

Page 13: Rest web services

Deploying the JAX-RS service in MuleDeploying 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"/>

Page 14: Rest web services

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.

Page 15: Rest web services

Thank you


Recommended