Representational State Transfer (REST)

BYPrabhat Gangwar

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

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)

Web

Ser

ver

HTTP POST PO.xmlPO(HTML/XML)

HTTP GET request /items

HTTP responseURL to submitted PO

List ofItems

ItemData

PO

HTTP responseResponse(HTML/XML doc)

HTTP responseResponse(HTML/XML doc)

HTTP GET request /00345Time

A user session

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 system1. Identify resources, e.g. list of items, detail of an item, purchase

order2. Create a URL for every resource[use nouns, not verbs]

http://www.company.com/items/00345Instead of

http://www.company.com/items/getItem?id=003453. Categorize resources:

• Accessible via HTTP GET (read-only)• Accessible also via POST, PUT, DELETE (modifiable)

4. Connect resources through hyperlinks 5. Specify the format of the response using a schema, e.g. DTD, W3C

schema, RelaxNG (also take care of POST or PUT services)6. 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 technologyStructure Accessibility Extensibility Performance Security

REST Inter-connections(hyperlinks)

GET, PUT, POST,DELETE(uniform interface)

Yes, through links

GET-base URIs are cacheable

Can apply {GET, PUT, POST, DELETE} permissions to a data object

SOAP RPC

OO paradigm of encapsulatingdata

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

Guidelineshttp://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