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 Client Server

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 Client Server Client Self 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 Client Server Client $ 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 Client Server Client Same 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 Client Interim Node Client Intermediary nodes can view the message and act upon it $ Server Other Interim Client

Sub Styles – Code On Demand Extend client functionality (extensibility) Client simplification Con: Reduces visibility This is an optional constrain Client Interim Node Client Scripts can be downloaded to add features to clients $ Server Other Interim Client

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 M R (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 H T T P

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.

Rest introduction

More Related Content

What's hot

Viewers also liked

Similar to Rest introduction

Recently uploaded

Rest introduction

Editor's Notes