Abstraction Layers

Outline (Abstraction Layers)

Abstraction Layers [3]
REST: The Definition [6]
Web Architecture [6]
1. Uniform Resource Identifier (URI) [2]
2. Hypertext Transfer Protocol (HTTP) [3]

Abstraction Layers E. Wilde: RESTful Organizing Systems

(4) What is REST?

Defining Representational State Transfer: 3 popular definitions

An architectural style for building loosely coupled systems
- defined by a set of general constraints (principles)
- the Web (URI/HTTP/HTML/XML) is an instance of this style
The Web used correctly (i.e., not using the Web as transport)
- HTTP is built according to RESTful principles
- services are built on top of Web standards without misusing them
- most importantly, HTTP is an application protocol (not a transport protocol)
Anything that uses HTTP and XML (XML without SOAP)
- XML-RPC was the first approach for this
- violates REST because there is no uniform interface

Abstraction Layers E. Wilde: RESTful Organizing Systems

(5) Architectural Styles

Architectural Style vs. Architecture
- Architectural Style: General principles informing the creation of an architecture
- Architecture: Designing a solution to a problem according to given constraints
- Architectural styles inform and guide the creation of architectures

Architecture: Louvre [http://en.wikipedia.org/wiki/Louvre]
Architectural Style: Baroque [http://en.wikipedia.org/wiki/Baroque_architecture]

Architecture: Villa Savoye [http://en.wikipedia.org/wiki/Villa_Savoye]
Architectural Style: International Style [http://en.wikipedia.org/wiki/International_Style_(architecture)]

Abstraction Layers E. Wilde: RESTful Organizing Systems

(6) REST is not an Architecture

REST is an architectural style
- distilled from the Web a posteriori
- some of the Web's standards and practices are not perfectly RESTful
The Web is an information system following REST
It is possible to design other RESTful information systems
- different uniform interfaces (not using HTTP's methods)
- different representations (not using HTML or XML)
- different identification (not using URIs)

REST: The Definition

Outline (REST: The Definition)

Abstraction Layers [3]
REST: The Definition [6]
Web Architecture [6]
1. Uniform Resource Identifier (URI) [2]
2. Hypertext Transfer Protocol (HTTP) [3]

REST: The Definition E. Wilde: RESTful Organizing Systems

(8) The REST Architectural Style

A set of constraints that inform an architecture

Resource Identification [Resource Identification (1)]
Uniform Interface [Uniform Interface (1)]
Self-Describing Messages [Self-Describing Messages (1)]
Hypermedia Driving Application State [Hypermedia Driving Application State (1)]
Stateless Interactions [Stateless Interactions (1)]

Claims: scalability, mashup-ability, usability, accessibility

REST: The Definition E. Wilde: RESTful Organizing Systems

(9) Resource Identification

Name everything that you want to talk about
Thing in this case should refer to anything
- products in an online shop
- categories that are used for grouping products
- customers that are expected to buy products
- shopping carts where customers collect products
Application state also is represented as a resource
- next links on multi-page submission processes
- paged results with URIs identifying following pages

REST: The Definition E. Wilde: RESTful Organizing Systems

(10) Uniform Interface

The same small set of operations applies to everything [Resource Identification (1)]
A small set of verbs applied to a large set of nouns
- verbs are universal and not invented on a per-application base
- if many applications need new verbs, the uniform interface can be extended
- natural language works in the same way (new verbs rarely enter language)
Identify operations that are candidates for optimization
- GET and HEAD are safe operations
- PUT and DELETE are idempotent operations
- POST is the catch-all and can have side-effects
Build functionality based on useful properties of these operations

REST: The Definition E. Wilde: RESTful Organizing Systems

(11) Self-Describing Messages

Resources are abstract entities (they cannot be used per se)
- Resource Identification [Resource Identification (1)] guarantees that they are clearly identified
- they are accessed through a Uniform Interface [Uniform Interface (1)]
Resources are accessed using resource representations
- resource representations are sufficient to represent a resource
- it is communicated which kind of representation is used
- representation formats can be negotiated between peers
Resource representations can be based on different constraints
- XML and JSON can represent the same model for different users
- whatever the representation is, it must support links [Hypermedia Driving Application State (1)]

REST: The Definition E. Wilde: RESTful Organizing Systems

(12) Hypermedia Driving Application State

Resource representations [Self-Describing Messages (1)] contain links to identified resources [Resource Identification (1)]
Resources and state can be used by navigating links
- links make interconnected resources navigable
- without navigation, identifying new resources is service-specific
RESTful applications navigate instead of calling
- representations [Self-Describing Messages (1)] contain information about possible traversals
- the application navigates to the next resource depending on link semantics
- navigation can be delegated since all links use identifiers [Resource Identification (1)]

REST: The Definition E. Wilde: RESTful Organizing Systems

(13) Stateless Interactions

This constraint does not say Stateless Applications!
- for many RESTful applications, state is an essential part
- the idea of REST is to avoid long-lasting transactions in applications
Statelessness means to move state to clients or resources
- the most important consequence: avoid state in server-side applications
Resource state is managed on the server
- it is the same for every client working with the service
- when a client changes resource state other clients see this change as well
Client state is managed on the client
- it is specific for a client and thus has to be maintained by each client
- it may affect access to server resources, but not the resources themselves
Security issues usually are important with client state
- clients can (try to) cheat by lying about their state
- keeping client state on the server is expensive (but may be worth the price)

Web Architecture

Outline (Web Architecture)

Abstraction Layers [3]
REST: The Definition [6]
Web Architecture [6]
1. Uniform Resource Identifier (URI) [2]
2. Hypertext Transfer Protocol (HTTP) [3]

Web Architecture E. Wilde: RESTful Organizing Systems

(15) What is the Web?

Web = URI + HTTP + ( HTML | XML )
RESTful Web uses HTTP methods as the uniform interface
- non-RESTful Web uses GET/POST and tunneled RPC calls
- a different RESTful Web uses Web Distributed Authoring and Versioning (WebDAV)
Imagine your application being used in 10 browsers
- resources to interact with should be identified [Resource Identification (1)] and linked [Hypermedia Driving Application State (1)]
- a user's preferred font size could be modeled as client state
- what about an access count associated with an API key?
Imagine your application being used in 10 browser tabs
- no difference as long as client state is representation-based
- cookies are shared across browser windows (different client scope)

Uniform Resource Identifier (URI)

Outline (Uniform Resource Identifier (URI))

Abstraction Layers [3]
REST: The Definition [6]
Web Architecture [6]
1. Uniform Resource Identifier (URI) [2]
2. Hypertext Transfer Protocol (HTTP) [3]

Uniform Resource Identifier (URI) E. Wilde: RESTful Organizing Systems

(17) Identifying Resources on the Web

Essential for implementing a Resource Identification [Resource Identification (1)]
URIs [http://dret.net/lectures/web-fall10/uri] are human-readable universal identifiers for stuff
- many identification schemes are not human-readable (binary or hex strings)
- many RPC-based systems do not have universally identified objects
Making every thing a universally unique identified thing is important
- it removes the necessity to scope non-universal identifiers
- it allows to talk about all things in exactly the same way
URI-identified things should have well-defined interactions

Uniform Resource Identifier (URI) E. Wilde: RESTful Organizing Systems

(18) Processing URIs

Processing URIs is not as trivial as it may seem
- escaping and normalization rules are non-trivial
- many implementations are broken
- complain about broken implementations
- even more complicated when processing an Internationalized Resource Identifier (IRI)
URIs are not just strings
- URIs are strings with a considerable set of rules attached to them
- implementing all these rules is non-trivial
- implementing all these rules is crucial
- application development environments provide functions for URI handling

Hypertext Transfer Protocol (HTTP)

Outline (Hypertext Transfer Protocol (HTTP))

Abstraction Layers [3]
REST: The Definition [6]
Web Architecture [6]
1. Uniform Resource Identifier (URI) [2]
2. Hypertext Transfer Protocol (HTTP) [3]

Hypertext Transfer Protocol (HTTP) E. Wilde: RESTful Organizing Systems

(20) RESTful Applications Talk HTTP

HTTP [http://dret.net/lectures/web-fall10/http] is essential for implementing a Uniform Interface [Uniform Interface (1)]
- HTTP defines a small set of methods for acting on URI-identified resources
Misusing HTTP turns application into non-RESTful applications
- they lose the capability to be used just by adhering to REST principles
- it's a bad sign when you think you need an interface description language
Extending HTTP turns applications into more specialized RESTful applications
- may be appropriate when more operations are required
- seriously reduces the number of potential clients

Hypertext Transfer Protocol (HTTP) E. Wilde: RESTful Organizing Systems

(21) HTTP Methods

Safe methods can be ignored or repeated without side-effects
- arithmetically safe: 41 × 1 × 1 × 1 × 1 …
- in practice, without side-effects means without relevant side-effects
Idempotent methods can be repeated without side-effects
- arithmetically idempotent: 41 × 0 × 0 × 0 × 0 …
- in practice, without side-effects means without relevant side-effects
Unsafe and non-idempotent methods should be treated with care
HTTP has two main safe methods: GET HEAD
HTTP has two main idempotent methods: PUT DELETE
HTTP has one main overload method: POST

Hypertext Transfer Protocol (HTTP) E. Wilde: RESTful Organizing Systems

(22) Cookies

Cookies [http://dret.net/lectures/web-fall10/webstorage#cookies] are client site state bound to a domain
- they are convenient because they work without having to use a representation
- they are inconvenient because they are not embedded in representations
Cookies are managed by the client
- they are shared across browser tabs
- they are not shared across browsers used by the same user
- essentially, the client model of cookies is a bit outdated
Two major things to look out for when using cookies:
1. session IDs are application state (i.e., non-resource state)
2. cookies break the back button (requests contain a URI/cookie combo)
The ideal RESTful cookie is never sent to the server
- cookies as persistent data storage on the client
- interactions with the server are only using URIs and representations

RESTful Organizing Systems

Principles and Patterns of Organizing Systems [./]
Spring 2011 — INFO 290-6 (CCN 42628)

Erik WildeUC Berkeley School of Information and UC Berkeley School of InformationRobert J. GlushkoUC Berkeley School of Information, UC Berkeley School of Information
2011-03-01

Contents

(2) Abstract

Abstraction Layers

Outline (Abstraction Layers)

(4) What is REST?

(5) Architectural Styles

(6) REST is not an Architecture

REST: The Definition

Outline (REST: The Definition)

(8) The REST Architectural Style

(9) Resource Identification

(10) Uniform Interface

(11) Self-Describing Messages

(12) Hypermedia Driving Application State

(13) Stateless Interactions

Web Architecture

Outline (Web Architecture)

(15) What is the Web?

Uniform Resource Identifier (URI)

Outline (Uniform Resource Identifier (URI))

(17) Identifying Resources on the Web

(18) Processing URIs

Hypertext Transfer Protocol (HTTP)

Outline (Hypertext Transfer Protocol (HTTP))

(20) RESTful Applications Talk HTTP

(21) HTTP Methods

(22) Cookies

(23) Conclusions

RESTful Organizing Systems

Principles and Patterns of Organizing Systems [./]Spring 2011 — INFO 290-6 (CCN 42628)

Erik WildeUC Berkeley School of Information and UC Berkeley School of InformationRobert J. GlushkoUC Berkeley School of Information, UC Berkeley School of Information2011-03-01

Contents

(2) Abstract

Abstraction Layers

Outline (Abstraction Layers)

(4) What is REST?

(5) Architectural Styles

(6) REST is not an Architecture

REST: The Definition

Outline (REST: The Definition)

(8) The REST Architectural Style

(9) Resource Identification

(10) Uniform Interface

(11) Self-Describing Messages

(12) Hypermedia Driving Application State

(13) Stateless Interactions

Web Architecture

Outline (Web Architecture)

(15) What is the Web?

Uniform Resource Identifier (URI)

Outline (Uniform Resource Identifier (URI))

(17) Identifying Resources on the Web

(18) Processing URIs

Hypertext Transfer Protocol (HTTP)

Outline (Hypertext Transfer Protocol (HTTP))

(20) RESTful Applications Talk HTTP

(21) HTTP Methods

(22) Cookies

(23) Conclusions

Principles and Patterns of Organizing Systems [./]
Spring 2011 — INFO 290-6 (CCN 42628)

Erik WildeUC Berkeley School of Information and UC Berkeley School of InformationRobert J. GlushkoUC Berkeley School of Information, UC Berkeley School of Information
2011-03-01