Rest.ppt

What is REST?

• REST stands for

Re

presentational

S

tate

T

ransfer.

REST is an

architecture style for designing networked applications.

• The idea is that, rather than using complex mechanisms such

as CORBA, RPC or SOAP to connect between machines,

simple HTTP is used to make calls between machines.

• Overview:

– Resources are defined and addressed

– Transmits domain-specific data over HTTP

REST is not a standard

• No W3C specification

• REST is built on the concepts:

– HTTP

(transferring mechanism)

– URL

(resource address)

– XML/HTML/GIF/JPEG

(Resource representations)

How Simple is REST?

•

Let's take a simple web service as an example: querying a phonebook application

for the details of a given user. All we have is the user's ID.

•

Using Web Services and SOAP, the request would look something like this:

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:body pb="http://www.acme.com/phonebook">

<pb:GetUserDetails>

<pb:UserID>12345</pb:UserID>

</pb:GetUserDetails>

</soap:Body>

</soap:Envelope>

• And with REST? The query will probably look like this:

http://www.acme.com/phonebook/UserDetails/12345

The letter analogy(REST vs. SOAP)

• A nice analogy for REST vs. SOAP is mailing a letter:

with SOAP, you're using an envelope; with REST, it's a

postcard.

• Postcards are easier to handle (by the receiver), waste

less paper (i.e., consume less bandwidth), and have a

short content. (Of course, REST requests aren't really

limited in length, if they use POST rather than GET.)

More Complex ReST Requests

• REST can easily handle more complex requests, including multiple

parameters. In most cases, you'll just use HTTP GET parameters in

the URL.

• For example:

http://www.acme.com/phonebook/UserDetails?

firstName=John&lastName=Doe

• If you need to pass long parameters, or binary ones, you'd normally

use HTTP POST requests, and include the parameters in the POST

body.

ReST Server Responses

• A server response in REST is often an XML file; for example,

<parts-list>

<part id="3322">

<name>ACME Boomerang</name> <desc>

Used by Coyote in <i>Zoom at the Top</i>, 1962 </desc>

<price currency="usd" quantity="1">17.32</price> <uri>http://www.acme.com/parts/3322</uri>

</part>

<part id="783">

<name>ACME Dehydrated Boulders</name> <desc>

Used by Coyote in <i>Scrambled Aches</i>, 1957 </desc>

<price currency="usd" quantity="pack">19.95</price> <uri>http://www.acme.com/parts/783</uri>

</part> </parts-list>

Web services: Company example

• Build a web service to enable its customers to

– Get list of items

W

eb

S

er

ve

r

HTTP POST

(HTML/XML)

PO

PO.xml

HTTP GET request

/items

HTTP response

URL to submitted PO

List of

Items

Item

Data

PO

HTTP response

HTTP response

HTTP GET request

/00345

Time

Get list of items

• Access the URL: http://www.company.com/items

• How the list is generated is invisible to the user (loose coupling)

• The following XML document returned:

Get detail of an item

• Accessing the URL: http://www.company.com/items/00345

• Any data change will not affect the user as in accessing

http://www.company.com/items/00345.html (restricts the resource;

whereas a database could be underneath)

Submit Purchase Order (PO)

• On the client, an instance is created, e.g. form

• client submits PO.xml as the payload of an HTTP POST

• The server responds to the POST with an URL

Characteristics

• Traversing links pulls representations

(pull-based client-server

interaction)

• Each request must be self-sufficient, not taking advantage of

any store resource

(stateless)

• Capability of storing responses to frequent requests

(cacheable

or non-cacheable)

• Resources are access via (HTTP) GET, POST, PUT, DELETE

(uniform interface)

• Every resource is named using an URL

(named resources)

• Resources are interconnected using URLs

(interconnected

resource representations)

• Intermediate components, e.g. proxy servers, gateways,

Steps in creating a RESTful system

1.

Identify resources

, e.g. list of items, detail of an item, purchase

order

2.

Create a URL for every resource

[use

nouns

, not verbs]

http://www.company.com/items/00345

Instead of

http://www.company.com/items/getItem?id=00345

3.

Categorize resources:

•

Accessible via HTTP GET (read-only)

•

Accessible also via POST, PUT, DELETE (modifiable)

4.

Connect resources through hyperlinks

5.

Specify the format of the response using a schema, e.g. DTD, W3C

schema, RelaxNG (also take care of POST or PUT services)