Web Architecture Services 2 Representational State Transfer REST

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

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

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 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 (Web. DAV) - 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 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

REST principles • 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

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