Representational State Transfer (REST)

Web Architecture [./]
Fall 2008 — INFO 290-03 (CCN 42584)

Erik WildeUC Berkeley School of Information, UC Berkeley School of Information
2008-09-23

[http://creativecommons.org/licenses/by/3.0/]

This work is licensed under a CC
Attribution 3.0 Unported License [http://creativecommons.org/licenses/by/3.0/]

Contents E. Wilde: Representational State Transfer (REST)

Contents

2Abstract
3The Web as a System
4Web System Design
1 Technologies and Implementations
- 6Object-Orientation
- 7Technologies are Tools
- 8Implementations are Products
2 REST Principles
- 10Definition
- 11Resources
- 12State
- 13Establishing a Common Model
- 14Nouns
- 15Verbs
- 16POSTing
- 17Content Types
- 18REST vs. Web Services
3 REST Implementation
- 20REST Technologies
- 21URIs
- 22HTTP
- 23XML
4 Conclusions
- 25Better Services

E. Wilde: Representational State Transfer (REST)

(2) Abstract

Representational State Transfer (REST) is an architectural style for building distributed systems. The Web is an example for such a system. REST-style applications can be built using a wide variety of technologies. REST's main principles are those of resource-oriented states and functionalities, the idea of a unique way of identifying resources, and the idea of how operations on these resources are defined in terms of a single protocol for interacting with resources. REST-oriented system design leads to systems which are open, scalable, extensible, and easy to understand.

E. Wilde: Representational State Transfer (REST)

(3) The Web as a System

The Web is one distributed hypermedia system
- the main architectural components are URIs, HTTP, and HTML
- all other Web technologies are built on that foundation
- if they are not, they are very likely not well-designed Web technologies
The Web is amazingly open, scalable, extensible, and easy to understand
- openness allows new technologies to be introduced
- scalability ensures that the system does not contain bottlenecks
- extensibility allows the Web to evolve without any redesign of existing parts
- simplicity makes sure that the system survives and evolves
No other information system gets even close to the Web
- but not all information system designs can accept the Web's limitations
- REST should be seen as a guideline how to build a true Web application
- other applications will continue to be built using other approaches

E. Wilde: Representational State Transfer (REST)

(4) Web System Design

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare [http://en.wikipedia.org/wiki/Charles_Antony_Richard_Hoare], The Emperor's Old Clothes, 1980 Turing Award Lecture [http://dret.net/biblio/reference/hoa81]

Technologies and Implementations

Outline (Technologies and Implementations)

Technologies and Implementations [3]
REST Principles [9]
REST Implementation [4]
Conclusions [1]

Technologies and Implementations E. Wilde: Representational State Transfer (REST)

(6) Object-Orientation

Object-Orientation is a Software Engineering Style
- it can be applied to any programming language
- depending on the language, this is more or less easy
- OO languages support or even enforce certain design patterns
- spaghetti code can be written in every programming language
Implementations can always be bad or good
- the quality of the implementation depends on the programmer
- programmers can be better supported and controlled with an OO language
- implementation quality metrics must be based on the product, not the language
Good programmers always produce good code
Bad programmers always produce bad code
Average programmers need good tools to produce good code

Technologies and Implementations E. Wilde: Representational State Transfer (REST)

(7) Technologies are Tools

Technologies help solving problems
- they are built with certain goals in mind
- they specialize in solving a problem in a specific way
Technology choices are very important
- the technology (i.e., the tool) shapes the way how a problem is solved
- working against the tool is possible, but hard and rarely done
Technologies sometimes cloud the more important issues
1. the problem must be well-defined and fully understood
2. the general approach to solve a problem must be identified
3. finally, a technology supporting this approach must be chosen

Technologies and Implementations E. Wilde: Representational State Transfer (REST)

(8) Implementations are Products

Implementations are built on (and shaped by) technologies
Implementation = Concepts + Technologies
Implementation quality depends on both factors
- the right choice of technologies is very important
- the responsible use of that foundation is equally important
Good REST is as hard to grasp as good OO
- products may claim that they are REST/OO
- they may even use technologies which support REST/OO
- only careful inspection reveals the truth of this claim
- in most cases, this only happens when the product needs to be changed

REST Principles

Outline (REST Principles)

Technologies and Implementations [3]
REST Principles [9]
REST Implementation [4]
Conclusions [1]

REST Principles E. Wilde: Representational State Transfer (REST)

(10) Definition

Resources are defined by URIs
Resources are manipulated through their representations
Messages are self-descriptive and stateless
There can be multiple representations for a resource
Application state is driven by resource manipulations

REST Principles E. Wilde: Representational State Transfer (REST)

(11) Resources

Resources are defined by URIs
- resources can never be accessed or manipulated directly
- REST works with resource representations
Resources are all the things we want to work with
- if you cannot name something, you cannot do anything with it
- a popular resource type on the Web are documents
- documents usually are a structured collection of information
Documents are abstract concepts of descriptive resources
- they may be used in different contexts (e.g., formats)
- different applications may be interested in different representations
- the underlying resource is always the same

REST Principles E. Wilde: Representational State Transfer (REST)

(12) State

State is represented as part of the content being transferred
- server interruptions do not create problems for the client
- it is possible to switch between servers for different interactions
- clients can simply store the representation to save the state
State transfer makes the system scalable
- data transfer is not state-specific (no stateful connection handling)
- state is transferred between client and server

REST Principles E. Wilde: Representational State Transfer (REST)

(13) Establishing a Common Model

Distributed systems must be based on a shared model
- traditional systems must agree on a common API
- REST systems structure agreement into three areas
REST is built around the idea of simplifying agreement
- nouns are required to name the resources that can be talked about
- verbs are the operations that can be applied to named resources
- content types define which information representations are available

REST Principles E. Wilde: Representational State Transfer (REST)

(14) Nouns

Nouns are the names of resources
- in most designs, these names will be URIs
- URI design is a very important part of a REST-based system design
Everything of interest should be named
- by supporting well-designed names, applications can talk about named things
- new operations and representations can be introduced
Separating nouns from verbs and representations improves extensibility
- applications might still work with resources without being able to process them
- introducing new operations on the Web does not break the Web
- introducing new content types on the Web does not break the Web

REST Principles E. Wilde: Representational State Transfer (REST)

(15) Verbs

Operations which can be applied to resources
The core idea of REST is to use universal verbs only
- universal verbs can be applied to all nouns
For most applications, HTTP's basic methods are sufficient
- GET: Fetching a resource (there must be no side-effects)
- PUT: Transfers a resource to a server (overwriting if there already is one)
- POST: Adds to an existing resource on the server
- DELETE: Discards a resource (its name cannot be used anymore)
Corresponding to the most popular basic database operations
- CRUD: Create, Read, Update, Delete

REST Principles E. Wilde: Representational State Transfer (REST)

(16) POSTing

POST adds instead of an overwriting update
POST can have different effects
- by POSTing, state is changed and a new resource is created
- by POSTing, only the existing resource is changed
- the server signals the difference using HTTP responses (200 OK or 201 Created)
This is a design choice
- if the added information needs to be accessible individually, create a new resource
- for changes of an existing resource, no new resource has to be created
Make sure that resources are navigable using URIs
- if appropriate, a relationship can be represented in the resource format

REST Principles E. Wilde: Representational State Transfer (REST)

(17) Content Types

Representations should be machine-processable
- they don't have to, they may be opaque to applications
- in many cases, machine-processable representations are advantageous
Resources are abstractions, REST passes representations around
- resources can have various representations (i.e., content types)
- clients can request content types they are interested in
Adding or changing content types does not change the system architecture
- different clients and servers support different content types
- Content Negotiation [Web Foundations (URI & HTTP); Content Negotiation (1)] allows content types to be negotiated dynamically

REST Principles E. Wilde: Representational State Transfer (REST)

(18) REST vs. Web Services

REST is a description of the Web's design principles
- it is not something new, it is simply a systematic view of the Web
- REST's claim is to be able to learn from the Web's success
Web Services (the SOAP flavor) do not build on REST
- they use HTTP as a transport protocol
- they re-create Web functionality through additional specifications (WS-*)
- they have been built by programmers using a top-down approach
REST and Web Services have different design approaches
- REST starts at the resources and takes everything from there
- Web Services focus on messages, which in most cases are operations

REST Implementation

Outline (REST Implementation)

Technologies and Implementations [3]
REST Principles [9]
REST Implementation [4]
Conclusions [1]

REST Implementation E. Wilde: Representational State Transfer (REST)

(20) REST Technologies

REST is not tied to a particular set of technologies
- URIs [URIs (1)] are the most common choice for nouns
- HTTP [HTTP (1)] methods are the most common choice for verbs
- XML [XML (1)] is the most common choice for content types
Choosing other technologies should have a very good reason
- building a REST system should make it open and accessible
- technology choices are as important as architectural choices

REST Implementation E. Wilde: Representational State Transfer (REST)

(21) URIs

REST requires a lot of URI design
- instead of being generated as a side-effect, they are the core of the system
Designing URIs and starting from them is a new way of thinking
- URIs are much more powerful than just being an address of a Web page
URIs are names for concepts
- concepts are never transmitted, only their representation
- having to focus on concepts rather than representations is helpful

REST Implementation E. Wilde: Representational State Transfer (REST)

(22) HTTP

HTTP is the most successful RESTful protocol
- HTTP's author Roy Fielding coined the term REST in his Ph.D. thesis [http://dret.net/biblio/reference/fie00]
HTTP should be regarded as an application-level protocol
- Web Service technologies use HTTP as a transport protocol
- HTTP has much more to offer than a firewall-penetrating pipe
Web infrastructure is built around proper HTTP usage
- caching is built into HTTP and caches optimize the Web transparently
- authentication can be done using HTTP's authentication methods
- secure data transfer can be done using HTTP over SSL (HTTPS) [Security Issues; HTTP over SSL (HTTPS) (1)]

REST Implementation E. Wilde: Representational State Transfer (REST)

(23) XML

URI-identified resources are abstract concepts
- for machine-based processing, XML is a good representation
- for human-oriented interactions, HTML probably is a better choice
Connections to other resources must be done by URI
- XML does not make built-in assumptions about identifiers
- but it does support URIs, for example with XInclude and XML Base
- RESTful applications are about navigating a Web of URI-identified resources

Conclusions

Outline (Conclusions)

Technologies and Implementations [3]
REST Principles [9]
REST Implementation [4]
Conclusions [1]

Conclusions E. Wilde: Representational State Transfer (REST)

(25) Better Services

REST is an architectural style
- URI/HTTP/HTML/XML may be replaced
- the general principle of resource-based interaction remains valid
RESTful system designs can create better systems
- a little bit more design effort in the beginning
- a lot less headaches later
SOA often are not really RESTful
- SOA often focuses on operations
- REST focuses on resources
RESTful design is a good starting point for OO implementations

2008-09-23 Web Architecture [./]
Fall 2008 — INFO 290-03 (CCN 42584)