Abstract

Representational State Transfer (REST) is an architectural style for building distributed systems. The WWW is an example for such a system. REST-style applications can be built using a wide variety of technologies. REST's main principles are that 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

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

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 = Product + Technologies
• Implementation quality depends on both factors
  • the right choice of technologies is very important
  • the right 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

Web Servers

• Web Servers provide a service
  • Web pages can be retrieved (by a client)
  • Web pages can be uploaded to the server
  • clients can submit (HTTP POST) data to a resource
  • Web pages can be removed from the server
  • the original design of the Web was a writable Web
• For complex interactions, more operations are required
  • Web Distributed Authoring and Versioning (WebDAV) defines additional HTTP methods
  • the basic HTTP methods may not always be sufficient
  • if required, additional methods on resources can be defined
  • if possible, these should be reusable for many resource types

Web Distributed Authoring and Versioning (WebDAV)

• HTTP alone is not sufficient for server-based editing
• WebDAV was developed as an extension of HTTP
  • authoring is supported by more methods for write-access
  • versioning was dropped from the feature list because of complexity
• WebDAV provides additional HTTP methods
  • LOCK and UNLOCK for remote editing
  • MKCOL for creating new collections
  • PROPFIND and PROPPATCH for metadata manipulation
• WebDAV would be implemented differently today
  • most methods are not necessary and could be mapped to existing HTTP methods
  • LOCK and UNLOCK could be regarded as fundamental

Web Technologies

• Web technologies must work in a RESTful way
  • resources are identified by URIs and can be navigated
  • resources have a state and can be accessed using HTTP
  • state transitions are modeled as resource accesses
• If applications work different, they are not Web technologies
  • they (or their data) may be accessible over the Web
  • they may be integrated into Web browsers
  • but they violate basic architectural principles of the Web
• Plug-ins other than single-presentation resources
  • PDFs break a lot of browser navigation features
  • Java applets are inaccessible from the outside
  • Flash applications are inaccessible from the outside

Services!

• Web technologies discovered by software engineers
  • the Web is not a single distributed program
  • instead, it is built around resources and their manipulation
  • loose coupling is good and allows system evolution
• Building large distributed programs is hard
  • given enough resources, software engineers may be able to build one
  • the result is extremely complex, and virtually impossible to maintain
  • too much code which has a lot of interdependencies
• Instead of building a program, work with resources
  • interaction is built around exchanging resource (representations), not sharing APIs
  • much better decoupling, much fewer dependencies

SOA Elements

SOA vs. REST

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
• Loose coupling not only applies to API vs. document
  • by transferring state, clients and server are decoupled state-wise
  • this makes the handling of interactions much easier

Establishing a Common Model

• Distributed systems must be based on a shared model
  • traditional systems must agree on a common API
  • SOA systems must agree on a number of messages (WSDL)
  • 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 can signal the difference using different HTTP responses
• 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

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 Claims

• Caching improves response time and reduces server load
• Less communication state enables easier load balancing between servers
• Less specialized software because the underlying technologies are simple
• Identification is done using standard mechanisms, no additional names necessary

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 WS-* specifications
  • they have been built by programmers from the top-down
• 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 Tests

• POSTable resources should be GETable as well
  • and I should see the results of my previous POSTs
• Server restarts should not affect the client

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

Syllabus Viewer Application (SylViA)

• Syllabus information should be available in a common format
  • there must be a schema for describing the syllabus information
  • there must be an application for processing syllabus information
• SylViA is based on a XML and an XML pipelining framework
  • syllabi are described in a format described by an XML Schema
  • semesters are described by calendar information
  • syllabus information is copied to the directory of a semester
  • HTTP requests are processed by processing calendar and syllabus information
• SylViA adoption so far has been disappointing
  • only very few teachers are willing to maintain their syllabus in XML
  • after each update, the syllabus must be uploaded to SylViA's directory

Everything is a Resource

• Instead of having everything internal, SylViA should externalize resources
  • syllabus information should be able to live anywhere on the Web
  • there could be input filters for accepting non-XML representations
  • everything works as long as resources can be transformed to SylViA XML
• Semester information is also a resource which should be accessible
  • when a new course is added, it needs to be added to the semester description
  • instead of adding the resource, its URI should be added
• REST requires us to design everything in using PUT, GET and POST
  • adding a syllabus means POSTing it to the right place: …/ischool/f06/ → URI
  • updating a syllabus means PUTting a new version of it
  • withdrawing a syllabus means removing its resource: DELETE …/ischool/f06/290-3
  • SylViA could be fully accessed using a browser (plus Poster)

Advantages of RESTification

• Open system design encourages reuse and interworking
  • REST operations can be easily implemented in other applications
  • interaction with SylViA depends only on URIs and HTTP and XML
• Allowing different syllabus representations
  • various content types can be used to describe syllabi
  • XML and HTML are already implemented in the system
  • text-based representations could improve SylViA adoption
  • REST allows this new type to be added without changing names or verbs

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