Representational State Transfer (REST)

Andrei Ioni a.ionita@jacobs-university.de

KWARC Research Group and DFKI Lab Bremen June, 2007

What is REST?
Network Architectural style Coined by Roy Fielding in his Ph.D. dissertation in 2000 Overview:
Resources are defined and addressed Transmits domain-specific data over HTTP Does not have any SOAP messaging layer or HTTP cookies

Resources
Web is comprised of resources, e.g. BMW defines Z4 Coup as a resource Users access it with the URL: http://www.bmw.com/en/newvehicles/Z4/Coupe A representation is returned, e.g.Z4Coupe.html This representation puts the client application in a state Accessing another hyperlink, e.g. accessories transfers the client application into another state

REST is not a standard

No W3C specification (EDIT: But there is an XML database that has such an API: eXist) REST is built on the concepts:
HTTP (transferring mechanism) URL (resource address) XML/HTML/GIF/JPEG (Resource representations) text/xml, text/html, image/gif, image/jpeg (MIME types)

Web services: Company example

Build a web service to enable its customers to
Get list of items Get details about a particular item Purchase Order (PO)

A user session
HTTP GET request
Response (HTML/XML doc)

/items HTTP response

List of Items

HTTP GET request

Time
Response (HTML/XML doc)

/00345

Web Server

HTTP response

Item Data

HTTP POST

PO (HTML/XML)

PO.xml

PO HTTP response

URL to submitted PO

Get list of items

Access the URL: http://www.company.com/items How the list is generated is invisible to the user (loose coupling) The following XML document returned:

Each item is retrieved via other links (key feature)

Get detail of an item

Accessing the URL: http://www.company.com/items/00345 Any data change will not affect the user as in accessing http://www.company.com/items/00345.html (restricts the resource; whereas a database could be underneath)

Again, more in-depth links appear, enabling to more detailed information

Submit Purchase Order (PO)

On the client, an instance is created, e.g. form client submits PO.xml as the payload of an HTTP POST The server responds to the POST with an URL The order is shared information between the company and the client (the client may DELETE it)

Characteristics
Traversing links pulls representations (pull-based client-server interaction) Each request must be self-sufficient, not taking advantage of any store resource (stateless) Capability of storing responses to frequent requests (cacheable or non-cacheable) Resources are access via (HTTP) GET, POST, PUT, DELETE (uniform interface) Every resource is named using an URL (named resources) Resources are interconnected using URLs (interconnected resource representations) Intermediate components, e.g. proxy servers, gateways, firewalls, etc. can be inserted between clients and resources for performance, security (layered components)

Steps in creating a RESTful system

1. Identify resources, e.g. list of items, detail of an item, purchase order 2. Create a URL for every resource [use nouns, not verbs] http://www.company.com/items/00345 Instead of http://www.company.com/items/getItem?id=00345 3. Categorize resources:
Accessible via HTTP GET (read-only) Accessible also via POST, PUT, DELETE (modifiable)

4. 5. 6.

Connect resources through hyperlinks Specify the format of the response using a schema, e.g. DTD, W3C schema, RelaxNG (also take care of POST or PUT services) Describe how your services should be invoked (in a WSDL or HTML document)

REST Constrains (1)

Client/Server constraints
Separation of Concerns Independent evolution of Components

Stateless Constraint
Single request reveals everything Easier to recover from failures Server does not commit resources to each request May degrade network performance when having large requests

Caching constraint
Eliminates interactions Clients have the right to reuse cacheable data May degrade reliability due to stale data

REST Constrains (2)

Uniform interface constrain
Implementation decoupled from interfaces - Adapting degrades efficiency

- Layered system constraint

- Architecture can be build hierarchically - Added Overhead

- Code-on-demand (inactive code is executed on the client when the user requests it)

Advantage to SOAP technology

Structure Accessibility
GET, PUT, POST, DELETE (uniform interface)

Extensibility Performance
Yes, through links

Security

REST

Interconnections (hyperlinks)

GET-base URIs Can apply {GET, PUT, are cacheable

POST, DELETE} permissions to a data object

SOAP RPC

OO paradigm of encapsulating data

Specific and numerous methods

Cannot refer to other objects outside the system

Not cached by any existing technology

Have to implement suitable strategy

References

Main reference:
Roger L. Costello, Building the Web Services the REST way, http://www.xfront.com/REST-Web-Services.html

Additional references:
Paul Prescod, Second Generation Web Services, http://webservices.xml.com/pub/a/ws/2002/02/06/rest.html?page=1 Wikipedia article, http://en.wikipedia.org/wiki/Representational_State_Transfer Henning Niss, REST for Web Services http://www.itu.dk/courses/IWSJ/E2005/slides/lecture7.pdf Hao He, Implementing REST Web Services: Best Practices and Guidelines http://www.xml.com/pub/a/2004/08/11/rest.html?page=1 Ryan Tamayko, How I explained REST to my wife http://tomayko.com/articles/2004/12/12/rest-to-my-wife