rest introduction

REST

Prof. William Martínez Pomares

Agenda

Basic Concepts Constrains or Sub Styles About Resources REST and Services

REST

Roy Fielding described REST as an architecture style which attempts “to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations"

Roy T Fielding. REST Disseration at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

REST

Separation of resource from representation

Manipulation of resources by representations

Self-descriptive messages Hypermedia as the engine of application

state (HATEOAS).

Sub Styles – Client Server

Separation of Concerns Improve Portability of UI Scalability per simple server components Independent evolution

ClientClient ServerServer

Sub Styles – CS+Stateless Com

No context in server, session in client All info needed is in message Visibility, reliability, and scalability Con: Decrease network performance

ClientClientServerServer

ClientClientSelf Described Message with all

info needed for operation

Sub Styles – CSS+Cache

Interactions partially or completely eliminated Reduced latency in average Con: Decrease on reliability, cached data may

not be the recently updated


ClientClient

$

Cache will avoid full trip to server, and allow less server work

Sub Styles CSSC + Uniform Interface

Principle of Generality on Interface Simple Architecture, better visibility Decoupling adds evolvability Con: Degrades efficiency Optimized: Large grain hypermedia transfer


ClientClientSame interface for all

interactions, servers and nodes

$

Sub Styles - Layered System

Restrict knowledge of system to 1 layer Bounds systems complexity + Encapsulation Intermediaries and load balancing Con: Add overhead and latency Optim: Pipes & Filters behavior with intermediaries

processing partially the message

ClientClientInterimNode

InterimNode

ClientClientIntermediary nodes can view the

message and act upon it

$

ServerServer

Other Interim

Other Interim

ClientClient

Sub Styles – Code On Demand

Extend client functionality (extensibility) Client simplification Con: Reduces visibility This is an optional constrain

ClientClientInterimNode

InterimNode

ClientClientScripts can be downloaded to

add features to clients

$

ServerServer

Other Interim

Other Interim

ClientClient

Architectural Elements-Data

How to render? Server, Client or mobile object REST: Data types + Metadata + Interface hiding Render in client… …using partially generated representation in

server… …with instructions in metadata for independent

engines


Resource is anything Membership function MR(t) (t=time) Maps Resource def to set of

Representations and Ids Static: Always returns the same set Semantics should be the same for all sets

of a resource


E.G. “My favorite song” set may vary over time

E.G. “The first song of Group X” is static. This add generality without types Allows late binding, requesting notion and

not a representation instance


Resource Representation Data, metadata, meta-metadata Data format is a Media Type Media Type definition is critical to user

perceived performance and actual processing needs.

Universal Interface

Identification of resources Manipulation through representations Self-descriptive messages Hypermedia as the engine of application

state .


Resource – The “it” Resource Id - URI Representation - HTML, JPEG, JSON Rep. Metadata – Headers (media-type) Res. Metadata – Source link, vary Control data - if-modified-since, cache-

control

Architec. Elements-Connectors

Client – HTTP library Server – Web Server API Cache – Browser cache Resolver - DNS Tunnel - SSL

Architec. Elements-Components

Origin Server – Apache, IIS Gateway – CGI, Squid Proxy – MS Proxy User Agent - Browser

Word on Resource Ids

URI, IRI, URN, URL Use for identification, maybe location URI is owned by server. URI is provided by server dynamically -

Discovered Nice URIs tempt developer to violate

discoverability URI should not expose internals

HTTP - Operations

GET Retrieve a representation Retrieve a representation if modified

(caching) DELETE

Delete the resource

HTTP - Operations

PUT Create a resource with client-side managed

instance id Update a resource by replacing Update a resource by replacing if not modified

(optimistic locking)

HTTP - Operations

POST Create a resource with server-side managed

(auto generated) instance id Create a sub-resource Partial update of a resource Partial update a resource if not modified

(optimistic locking)

REST – Usual Example

Obj. A

Obj. B

Obj. C

Res. A

Res. B

Res. C

HTTP

Usual Example

Mapping Each object in the domain is one resource There may be the need for additional

resources HTTP operations to manipulate know

resources Client to know what and how to post for

processing.

REST – Example Problems

This approach exposes model domain There is not encapsulation, nor data hiding Resources are passive Not using HATEOAS

REST – Alternative Example

Use Services as resources GET to bank/services resource returns an list of

request forms for consuming services Follow the links to forms, fill the forms and post. Post the form to a bank/cashier resource bank/cashier is a service! And a resource! Post a Loan Request form and get a Loan

Request ID

REST – Example Goodies

This approach is business domain oriented

Encapsulates processing Resources are active. Follows HATEOAS constrain. Not necessarily forms. Depends on app,

can use ATOM and ATOMPub.

Questions?

rest introduction

Technology