Representational State Transfer (REST) is a network architectural style that defines best practices for distributed hypermedia systems. It uses HTTP as a transfer mechanism and defines resources, which are any information that can be named, addressed, and linked. Resources are accessed via URIs and represented in different data formats like XML, JSON, and HTML. A RESTful API is designed around resources and uses HTTP verbs like GET, POST, PUT, and DELETE to operate on them. This allows uniform and stateless access to resources in a loosely coupled and scalable way.

1. Representational State
Transfer (REST)
BY
Prabhat Gangwar

2. 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

3. 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)

4. 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)

5. WebServer
HTTP POST PO.xml
PO
(HTML/XML)
HTTP GET request /items
HTTP responseURL to submitted PO
List of
Items
Item
Data
PO
HTTP response
Response
(HTML/XML doc)
HTTP response
Response
(HTML/XML doc)
HTTP GET request /00345
Time
A user session

6. 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)

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

8. 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)

9. 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)

10. 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. 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)

11. 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

12. 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)

13. Advantage to SOAP technology
Structure 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
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

14. 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