REST

REST
–

R
EPRESENTATIONAL

S
TATE

T
RANSFER


Presented by:
Gaurav

Agashe

A
GENDA

I.
What is REST?

II.
Why REST?

III.
Where is REST used?

IV.
Uniform Operations

V.
When to REST? And when not to..

W
HAT

R
EST

IS

NOT


REST is not a standard


You will not see the W3C putting out a REST
specification.


You will not see IBM or Microsoft or Sun selling a REST
developer's toolkit.


REST is just a
design pattern



You can't bottle up a pattern.


You can only understand it and design your Web
services to it.


REST does prescribe the
use
of standards:


HTTP (transfer state)


URL (resource identifier)


XML/HTML/GIF/JPEG/
etc.

(resource representations
)


text/xml, text/html,
image/gif
etc
.

(resource
t
ypes)

W
HAT

R
EST

IS

–

R
OY

F
IELDING


An
architecture style

is a coordinated set
of
architectural
constraints that restricts the
roles
and
features of architectural elements, and
the
allowed
relationships between those
elements,
within
any architecture that conforms to
that
style.


A
style can be applied to many
architectures


An
architecture can consist of many
styles


Why is it called

"Representational State Transfer"?

Resource

Client

http://
www.ics.uci.edu/about

index.html

The Client references a Web

resource using a URL.
A
r
epresentation
of
the resource is returned
(here
HTML document
).
The
representation
places
the client application in
a
state
. The
result
of
traversing a
hyperlink is that another
resource is accessed
.
The new representation places the
client application into a new
state. Thus, the client application changes (
transfer
s
)
state with
each resource representation
--
> Representation State Transfer!

…………………

…………………

….

W
HERE

IS

REST??


Web
is an example of a REST system
!


HTTP is the most common example of REST
based system.


All of those Web services that you have been
using all these many years
-

book ordering
services, search services
,
online dictionary
services,
etc

-

are REST
-
based Web services
.


Blogosphere, Atom Publishing Protocol


You can also create your own!

Characteristics of a REST
-
based Network

•
Client
-
Server
: a pull
-
based interaction style: consuming
components pull representations.

•
Stateless
: each request from client to server must contain all
the information necessary to understand the request, and cannot
take advantage of any stored context on the server.

•
Cache
: to improve network efficiency responses must be capable
of being labeled as cacheable or non
-
cacheable.

•
Uniform interface
: all resources are accessed with a generic
interface (e.g., HTTP GET, POST, PUT, DELETE).

•
Named resources
-

the system is comprised of
resources
which
are
named

using a URI.

•
Interconnected resource representations

-

the
representations of the resources are interconnected using URLs,
thereby enabling a client to progress from one state to another.

U
NIFORM

OPERATIONS

IN

REST


In common parlance these are CRUD
–

Create,
Read, Update and Delete


For HTTP these are: POST, GET, PUT, DELETE


Simplifies semantics


Simplifies client complexity


Simplifies application model

R
ETRIEVING

I
NFORMATION
: HTTP
GET

Amazon

Web Server

GET / HTTP/1.1

Host: http://www.amazon.com

http://
www.amazon.com

-

The user types in at his browser: http://www.amazon.com

-

The browser software creates an HTTP header (no payload)


-

The HTTP header identifies:



-

The desired action: GET ("get me resource")



-

The target machine (www.amazon.com)

U
PDATING

INFORMATION
: HTTP POST

Amazon

Web Server

POST / HTTP/1.1

Host: http://www.amazon.com

Book:
DaVince

Code

Credit Card: Visa

Number: 123
-
45
-
6789

Expiry: 12
-
04
-
06

-

The user fills in the Web page's form

-

The browser software creates an HTTP header with a payload


comprised of the form data


-

The HTTP header identifies:



-

The desired action: POST ("here's some update info")



-

The target machine (amazon.com)



-

The payload contains:



-

The data being
POSTed

(the form data)

Book: Da Vince Code

Credit Card: Visa

Number: 123
-
45
-
6789

Expiry: 12
-
04
-
06

H
EADER

AND

PAYLOAD

Amazon

Web Server

POST / HTTP/1.1

Host: http://www.amazon.com

Book:
DaVince

Code

Credit Card: Visa

Number: 123
-
45
-
6789

Expiry: 12
-
04
-
06

Book: Da Vince Code

Credit Card: Visa

Number: 123
-
45
-
6789

Expiry: 12
-
04
-
06

This information (the form data) is called the payload.

This information

(the HTTP data)
is called the

HTTP header

U
SER

S
ESSION

USING

REST

Web Server

HTTP POST

PO.xml

PO

(HTML/XML)

HTTP GET request

/items

HTTP response

URL to submitted PO

List of

Items

Item

Data

PO

HTTP response

Response

(HTML/XML doc)

HTTP response

Response

(HTML/XML doc)

HTTP GET request

/00345

Time

W
HEN

TO

REST? A
ND

WHEN

NOT

TO
..


Easier integration


Easier
for
humans to understand


Hypermedia systems like Web


Efficiency

No Hypermedia content

Integrating non
RESTful

stuff


Challenges
–
Security, getting the URI’s right etc.

C
ONCLUSION


REST is simple and easy to use


Designed alongside the HTTP specifications to
support the Web


Has issues related to security but is still
preferred over other architectures


Q
UESTIONS
?


A little REST and Relaxation : presentation by Roy Fielding


REST
and the Real World


http://
www.xml.com/pub/a/2002/02/20/rest.html


http
://www.ics.uci.edu/~
fielding/pubs/dissertation/top.htm


Second Generation Web Services


http://www.xml.com/pub/a/2002/02/06/rest.html


The REST architectural style : presentation by Robert Wilson

IBM
W
EB
S
PHERE

I.
WebSphere

Overview


II.
WebSphere

Goals


III.
WebSphere

Architecture


IV.
WebSphere

Features


W
EBSPHERE

O
VERVIEW


IBM’s
product


its
roots are in the
mid
-
1990s


based
on Java programming
language


IBM
launched
WebSphere

in
1998


gained
momentum with on
-
demand business
(2002
)

W
EB
S
PHERE

G
OALS


Integrate
all of a company’s existing data


Give
a Web front
-
end


Support
for business processes


Respond
to market fluctuations and new
industry supply chain requirements in real
-
time


Build
interactive Web
-
oriented applications
Support business functions needed for e
-
commerce




S
ET

OF

SOFTWARE

PRODUCTS

W
EB
S
PHERE

A
RCHITECTURE


W
EB
S
PHERE

F
EATURES


middleware application


transforms
the old business into SOA


is J2EE certified


Realizes multi
tier architectures


composed of:


server software


development products

this two parts are bundled into packages


The foundation of the software is
WebSphere

Application Server

(WAS)


W
EB
S
PHERE

F
EATURES
(2)


It works across all of its different operating
systems and applications


Unify the company’s
management


Different
tools help the different audiences


W
EB

S
ERVICE

G
ATEWAYS


Problems to address


Resolution objectives


IBM’s solution

P
ROBLEMS

TO

A
DDRESS


Growing threat of malicious web application
attacks


Web
applications written by many different
developers


Server configurations done by distributed systems
administrators


No centralized point of control for web application
security


R
ESOLUTION

OBJECTIVES


Ensure system & information security for web
services


Establish centralized point of control for web
application security


Minimize the number of directly accessible servers


Minimize the effort for web application developers


Maintain distributed systems administration


Keep the effort as transparent as possible to
customers


Enable seamless addition of web applications for new
projects


IBM’
S

SOLUTION
-

WEB

SERVICE

GATEWAYS


Runtime component that provides mapping
between based on WSDL documents (Service
Mapping)


Export Mapping


Import Mapping


Deployed at Firewall of an enterprise network


Transformation or requests


SOAP over JMS
-
> SOAP over HTTP


UDDI
publication and lookup


Security and Management

H
OW

IT

WORKS
?


Gateway configured with number of channels.


Transport channel
–

underlying transport
mechanism being used


Channel type can be specified for a service


Scenarios of use:


Handling inbound requests


Handling outbound requests


Example: A
StockQuote

Service deployed inside your
firewall and needs to be shared with Customers and
Partners.

H
ANDLING

INBOUND

REQUESTS
(1)

1.
Create WSDL Document that describes service


Soap address location
-
>
myhost

is inside firewall

H
ANDLING

INBOUND

REQUESTS
(2)

2.
Import WSDL document into the Gateway


supplying a name for the
service


selecting SOAP/HTTP
transport
channel


location
of the
StockQuote

WSDL
file


Gateway creates new modified WSDL file


H
ANDLING

INBOUND

REQUESTS
(3)

3.
Share the WSDL to requestors outside the
firewall


publish
the service to
UDDI


p
rovide copy to requestors directly from the Gateway


s
upply a URL which dynamically obtains WSDL from
the Gateway

H
ANDLING

INBOUND

REQUESTS
(4)

4.
Service requestors send SOAP messages to
Gateway which will invoke the
StockQuote

service inside the firewall.







C
ONCLUSION


T
raditional
non
-
web service ways of exposing
these applications and processed could lead to
problems of
maintenance, reliability and security


Web Service Gateways specific to requirements
can be built


O
THER

S
CENARIOS