Web Architecture & Services (2) Representational State Transfer (REST)

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. What is REST?

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 The Web as a System

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 Servers

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

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

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

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

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 Verbs

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 Content Negotiation Content Types

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 Claims

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

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 URIs

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

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 XML

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

Original Content: Copyright © 2006 Erik Wilde, UC Berkeley