Prof.

Dinkar Sitaram
Prof K V Subramaniam
Prof Ramesh Bhat
Prof Nirupama MP
Prof Samatha RS

CS352: REST
Source: Learn Rest in 18 slides, Suraj Gupta, OBeautifulCode.com, 2014

REST
Why Learn Rest

▪ Rest can help build client-friendly distributed

systems that are simple to understand and
simple to scale
▪ In other words
What is REST?

▪ Is it a standard?NO
 REST is a programming style
▪ An example protocol that uses REST –
▪ HTTP can also be used in a non-RESTful way
 Example: SOAP services that use http to transport data
Familiarity Check

▪ What is ▪ URI- naming an object

 URLs, URIs ▪ Hypertext – data with
 Hypertext meta-data
 Accept: text/html ▪ Format of data
 200OK, 404 not found
▪ Status
 GET/PUT/POST
▪ Operations
5 major concepts of REST
Resources

▪ Resource is a “Thing”
▪ You need to give an identifier for a “thing”
▪ Take for example “light on board in the
seminar hall”
▪ If you need to control it, you need to name it.
▪ For example
 /pesu/b-block/groundfloor/seminarhall/board/light/1

 Refers to the first light on the board. Each light

can be separately controlled.
URLs and URIs

URI – Uniform Resource URL – Uniform Resource

Identifier Locator
▪ The name of the object on ▪ Subset of an URI
the web ▪ Specifies where to find a
▪ Identifies a resource by resource – the location
 Name ▪ How to retrieve the
 Location resource
 Or both

REST design principle – Identify everything that is worth

being identified.
Representations

▪ How does a client ▪ Type/Form/Representa

know what to do tion – MIME types
 with data it receives  Over 1000 standard
 On fetching a URL MIME types
▪ RESTful systems → ▪ Can request in XML,
empowers client to ask JSON etc..
for data in a form they ▪ Example
understand GET /pages/archive HTTP/1.1
Host: obeautifulcode.com
Accept: text/html
Class Exercise (5 mins)

▪ Consider a web application for building a BookShop

using a web application
▪ Your shop should support
 Retrieve book details like price, recommendations
 Adding a book to a shopping cart
 Like a book
 Sending recommendation of a book to a friend
 Deleting a recommendation for a book.
▪ List out the resources for your application and the
representations if you would like to see the data in
JSON format
Solution

▪ Resources ▪ Representation
 Books  Accept: text/JSON
 Recommendations
 Shopping Cart
 Friend
Representations..

▪ Can we use different URLs for different

representations of the same resource
 https://bblock/seminarhall/board/light1.xml
 https://bblock/seminarhall/board/light1.html
▪ Not required. Use a different representation for
same resource.
▪ If server does not support requested MIME type
 Return standard error (HTTP 406)
▪ Using representations with negotiation allows
for flexibility
Operations

▪ When we develop applications, we think of

operations
▪ For BookKarts this could be
 GetListofBooks()
 AddBookToShoppingCart()
▪ Need to define these operations
▪ No standard style exists
▪ For functionality and side-effects – consult
the manual
Operations

REST Operations Usage

GET ▪ GET
• Retrieve representation of a resource  https://bblock/seminarhall/bo
ard/light1.xml
PUT  To check if light is ON
• Create or update resource by
replacement. ▪ POST to
 https://bblock/seminarhall/bo
POST ard/light1.xml
• Create or partial update of a resource  To turn on/off the light
DELETE  Put ON in the body of the
message
• Remove a resource
Operations..
Operations: Safe vs
Idempotent
Safe Idempotent
▪ Does not modify the ▪ Idempotent has no
resources additional effect if it is
▪ Example called more than once with
 GET same input parameters
▪ Can repeatedly perform
operations.
▪ No effect on servers
 How would you like to pay for
a seat multiple times?
Operations: Rules
Operati Safe Idempote When to use
on nt
GET Yes Yes Mostly for retrieving resources. Can call multiple
times.
PUT No Yes Modifies a resource but no additional impact if
called multiple times
POST No No Modifies resources, multiple calls will cause
additional effect if called with same parameter
DELETE No Yes Removing a resource.
Class Exercise

▪ For each of the operations, select the REST

operation to use for designing the Web APP
Application Operation REST Operation Justification
Retrieve book details
Adding a book to a
shopping cart
Like a book
Deleting a
recommendation for a
book.
Class Exercise - solution

▪ For each of the operations, select the REST

operation to use for designing the Web APP
Application Operation REST Operation Justification
Retrieve book details GET Just need to details; safe
Adding a book to a PUT Don’t want multiple copies of the
shopping cart book in the shopping card. So
idempotent
Like a book POST Does not matter if executed multiple
times. Non idempotent
Deleting a DELETE Remove the resource
recommendation for a
book.
Hypertext

▪ Data returned for a ▪ Example

resource <book
self=https://bookkarts.com/The
▪ Can contain embedded ChamberOfSecrets.xml
links <review
ref=“http://bookkarts.com/TheC
 Application can follow
hamberOfSecrets/Reviews.xml”>
these links
<price>INR 500</price>
 Key point: State of server
</book>
is transferred to the client
using hyperlinks
▪ Upto client to follow
hyperlinks.
What is application state?

▪ For many applications to function, state needs to

be maintained across requests
▪ Example
1. Login to a web-app like Book Karts
2. Buy a book
▪ Somehow the application has to keep track of
 The user who has made the request to buy the book
 The user has now authenticated to the app
▪ Who should keep track of this?
 Client?
 Server?
Statelessness

▪ REST mandates
 State be turned into
resource state or
 Client takes care of
state
▪ Server will not
maintain any
communication state
for a client
▪ Each client request is
treated independently
Statelessness - Benefits
No state saved on
server, so even if
▪ Clients isolated server fails, the client
connects to another
against changes on server and continue
server
▪ Promotes redundancy
- unlocks performance
 don’t really need to
know which server
client was talking to
 No synchronization
overhead
Errors

▪ HTTP response codes

are well defined
▪ Status codes grouped
into categories
 2xx means action
requested was
received, understood
and processed
successfully
 Body of response can
have details of errors
 Upto client on how
errors are handled
The reality of REST

▪ Resource state implementation is upto the

programmer
▪ If a system requires many resources then
REST is probably not a good choice
▪ Not good choice for real-time or bandwidth
constrained scenario due to large number of
messages exchanged
FURTHER READING
Common Objections to REST
Common Objections to REST
Video Watch

▪ The End of Cloud Computing - Peter Levine

 https://www.youtube.com/watch?v=l9tOd6fHR-U
()