RESTful Organizing Systems

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.

Abstract

What is REST?

Defining Representational State Transfer: 3 popular definitions1) An architectural style for building loosely coupled systems

o defined by a set of general constraints (principles) o the Web (URI/HTTP/HTML/XML) is an instance of this style

2) The Web used correctly (i.e., not using the Web as transport)o HTTP is built according to RESTful principles o services are built on top of Web standards without misusing

themo most importantly, HTTP is an application protocol (not

a transport protocol)3) Anything that uses HTTP and XML (XML without SOAP)

o XML-RPC was the first approach for thiso violates REST because there is no uniform interface

Architectural StylesArchitectural Style vs. Architecture

o Architectural Style: General principles informing the creation of an architecture

o Architecture: Designing a solution to a problem according to given constraints

o Architectural styles inform and guide the creation of architectures

o Architecture: Louvreo Architectural Style: Baroque

o Architecture: Villa Savoyeo Architectural Style: International Style

REST is NOT an Architectureo REST is an architectural style

o distilled from the Web a posteriorio some of the Web's standards and practices

are not perfectly RESTful

o The Web is an information system following REST

o It is possible to design other RESTful information systemso different uniform interfaces (not using HTTP's

methods)o different representations (not using HTML or XML)o different identification (not using URIs)

The REST Architectural Style

o A set of constraints that inform an architecture1. Resource Identification2. Uniform Interface3. Self-Describing Messages4. Hypermedia Driving Application State5. Stateless Interactions

o Claims: scalability, mashup-ability, usability, accessibility

Resource Identification

o Name everything that you want to talk about

o Thing in this case should refer to anythingo products in an online shopo categories that are used for grouping productso customers that are expected to buy productso shopping carts where customers collect products

Application state also is represented as a resourceo next links on multi-page submission processeso paged results with URIs identifying following pages

Uniform Interfaceo The same small set of operations applies to everything

o A small set of verbs applied to a large set of nounso verbs are universal and not invented on a per-application baseo if many applications need new verbs, the uniform interface can

be extendedo natural language works in the same way (new verbs rarely enter

language)

o Identify operations that are candidates for optimizationo GET and HEAD are safe operationso PUT and DELETE are idempotent operationso POST is the catch-all and can have side-effects

o Build functionality based on useful properties of these operations

Self-Describing Messageso Resources are abstract entities (they cannot be

used per se)o Resource Identification guarantees that they are clearly

identifiedo they are accessed through a Uniform Interface

o Resources are accessed using resource representationso resource representations are sufficient to represent a resourceo it is communicated which kind of representation is usedo representation formats can be negotiated between peers

o Resource representations can be based on different constraintso XML and JSON can represent the same model for different userso whatever the representation is, it must support links

Hypermedia Driving Application State

o Resource representations contain links to identified resources

o Resources and state can be used by navigating linkso links make interconnected resources navigableo without navigation, identifying new resources is service-

specific

o RESTful applications navigate instead of callingo representations contain information about possible traversalso the application navigates to the next resource depending on

link semanticso navigation can be delegated since all links use identifiers

Stateless Interactionso This constraint does not say Stateless Applications!

o for many RESTful applications, state is an essential parto the idea of REST is to avoid long-lasting transactions in applications

o Statelessness means to move state to clients or resourceso the most important consequence: avoid state in server-side

applications

o Resource state is managed on the servero it is the same for every client working with the serviceo when a client changes resource state other clients see this change as

well

o Client state is managed on the cliento it is specific for a client and thus has to be maintained by each cliento it may affect access to server resources, but not the resources

themselves

o Security issues usually are important with client stateo clients can (try to) cheat by lying about their stateo keeping client state on the server is expensive (but may be

worth the price)

What is the Web?o Web = URI + HTTP + ( HTML | XML )

o RESTful Web uses HTTP methods as the uniform interfaceo non-RESTful Web uses GET/POST and tunneled RPC callso a different RESTful Web uses Web Distributed Authoring and

Versioning (WebDAV)

o Imagine your application being used in 10 browserso resources to interact with should be identified and linkedo a user's preferred font size could be modeled as client stateo what about an access count associated with an API key?

o Imagine your application being used in 10 browser tabso no difference as long as client state is representation-basedo cookies are shared across browser windows (different ”client

scope”)

Identifying Resources on the Web

o Essential for implementing a Resource Identification

o URIs are human-readable universal identifiers for stuffo many identification schemes are not human-readable (binary or

hex strings)o many RPC-based systems do not have universally identified

objects

o Making every thing a universally unique identified thing is importanto it removes the necessity to scope non-universal identifierso it allows to talk about all things in exactly the same way

o URI-identified things should have well-defined interactions

Processing URIs

Processing URIs is not as trivial as it may seemo escaping and normalization rules are non-trivialo many implementations are brokeno complain about broken implementationso even more complicated when processing

an Internationalized Resource Identifier (IRI)

URIs are not just stringso URIs are strings with a considerable set of rules

attached to themo implementing all these rules is non-trivialo implementing all these rules is crucialo application development environments provide

functions for URI handling

RESTful Applications Talk HTTPo HTTP is essential for implementing a Uniform

Interfaceo HTTP defines a small set of methods for acting on URI-

identified resources

o Misusing HTTP turns application into non-RESTful applicationso they lose the capability to be used just by adhering to REST

principleso it's a bad sign when you think you need an interface

description language

o Extending HTTP turns applications into more specialized RESTful applicationso may be appropriate when more operations are requiredo seriously reduces the number of potential clients

HTTP Methodso Safe methods can be ignored or repeated without side-effects

o arithmetically safe: 41 × 1 × 1 × 1 × 1 …o in practice, without side-effects means without relevant side-effects

o Idempotent methods can be repeated without side-effectso arithmetically idempotent: 41 × 0 × 0 × 0 × 0 …o in practice, without side-effects means without relevant side-effects

o Unsafe and non-idempotent methods should be treated with care

o HTTP has two main safe methods: GET HEAD

o HTTP has two main idempotent methods: PUT DELETE

o HTTP has one main overload method: POST

Cookieso Cookies are client site state bound to a domain

o they are convenient because they work without having to use a representationo they are inconvenient because they are not embedded in representations

o Cookies are managed by the cliento they are shared across browser tabso they are not shared across browsers used by the same usero essentially, the client model of cookies is a bit outdated

o Two major things to look out for when using cookies:o session IDs are application state (i.e., non-resource state)o cookies break the back button (requests contain a URI/cookie combo)

o The ideal RESTful cookie is never sent to the servero cookies as persistent data storage on the cliento interactions with the server are only using URIs and representations

Conclusions

o REST is simple to learn and use

o Unlearning RPC in most cases is the hardest parto OO is all about identifying classes and methodso distributed systems very often are built around RPC modelso many classical IT architectures are RPC-centric by design

o REST and RPC do not mixo resource orientation ↔ function orientationo cooperation ↔ integrationo openly distributed ↔ hiding distributiono coarse-grained ↔ fine-grainedo complexity in resources formats ↔ complexity in function set

Number of SOAP vs. REST based APIs (Source: programmableweb.com)

REST wins out

© Erik Wilde and Robert J. Glushko, UC Berkeley School of Information