Upload
william-martinez-pomares
View
2.791
Download
0
Embed Size (px)
Citation preview
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
ClientClientServerServer
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
ClientClientServerServer
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
Architectural Elements-Data
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
Architectural Elements-Data
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
Architectural Elements-Data
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 .
Architectural Elements-Data
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?