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.

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

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, The Emperor's Old Clothes, 1980 Turing Award Lecture

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

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

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

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

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

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 Triangle

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

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

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

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 allows content types to be negotiated dynamically

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 (in their narrow sense) 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 Technologies

• REST is not tied to a particular set of technologies
  • URIs are the most common choice for nouns
  • HTTP methods are the most common choice for verbs
  • XML 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

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

HTTP

• HTTP is the most successful RESTful protocol
  • HTTP's author Roy Fielding coined the term REST in his Ph.D. thesis
• 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)

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

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