Rest Architecture and

Web Services- Mr. Roy Fielding-

1
2
3
 REST Intro
• Web services based on REST Architecture are
known as RESTful web services.
• These webservices uses HTTP methods to
implement the concept of REST architecture.
• A RESTful web service usually defines a URI,
Uniform Resource Identifier a service,
provides resource representation such as
JSON and set of HTTP Methods.

4
REST (REpresentational State Transfer)
• REST is the architectural style of the Web
• REST is a set of design criteria and not the
physical structure (architecture) of the system
• ‘Web’ applications are the most prevalent –
hence RESTful architectures run off of it

5
6
7
8
 Understanding REST – Resources
• Anything that’s important enough to be
referenced as a thing in itself
• Something that can be stored on a computer
and represented as a stream of bits:
– A document (e.g. information about Presidency)
– Row in DB (e.g. ‘User Profile’)
– Output of executing an algorithm (e.g. 100th Prime
number or Google Search)

9
 URIs and Resources{URI=URL + URN}
• URI is an ‘address’ of a resource
• A resource must have at least one URI
• URIs should be descriptive (human parse able)
and have structure. For Example:
– http://www.ex.com/software/releases/latest.tar.gz
– http://www.ex.com/map/roads/USA/CA/17_mile_drive
– http://www.ex.com/search/cs578
– http://www.ex.com/sales/2012/Q1
– http://www.ex.com/relationships/Alice;Bob

10
 Resources and URIs (Cont’d)
• Not so good URIs (everything as query parameters):
– http://www.ex.com?software=Prism&release=latest
&filetype=tar&method=fetch
– http://www.ex.com?
sessionId=1234567890876543212345678765432345678654323456788
76543&itemId=9AXFE5&method=addToCart
• URIs need not have structure/predictability but are
valuable (and easier) for the (human) clients to navigate
through the application
• May have multiple URIs to refer to same resource –
convenient but confusing
• Each URI must refer a unique resource – although they
may point to the ‘same one’ at some point in time (Ex.:
…/latest.tar.gz and …/v1.5.6.tar.gz)
11
 Understanding REST - Addressability
• An application is addressable if it exposes
interesting aspects of its data set as resources
• An addressable application exposes a URI for
every piece of information it might conceivably
serve
• Most important from end-user perspective
• Addressability allows one to bookmark URIs or
embed them in presentations/books etc. Ex.:
– google.com/search?q=CS578+USC
– Instead of
• Go to www.google.com
• Enter ‘CS578 USC’ (without quotes in search box)
• Click ‘Search’ or hit the ‘Enter key’
12
• URL-----https://www.amazon.in/
• URN-----Fossil-Touchscreen-Smartwatch-
Smartphone-Notifications/dp
• URI----- https://www.amazon.in/Fossil-Touchscreen-Smartwatch-Smartphone-Notifications/dp/B07SRVV8V4/ref=sr_1_2?
_encoding=UTF8&pf_rd_i=2563504031&pf_rd_m=A1VBAL9TL5WCBF&pf_rd_p=df4a8804-ab6e-49ab-9c6b-
98718690f9e3&pf_rd_r=22M9CPXGPTRQRGV23VAB&pf_rd_s=center-

1&pf_rd_t=Gateway&qid=1636710146&refinements=p_89%3AFossil&rnid=13 50388031&s=watc
URI=URL+URN----HTTP

13
 REST Principle #1
The key abstraction of information is a resource,
named by a URI. Any information that can be
named can be a resource

14
 Understanding REST -
Statelessness
• Every HTTP request happens in complete
isolation
– Server NEVER relies on information from prior
requests
– There is no specific ‘ordering’ of client requests
(i.e. page 2 may be requested before page 1)
– If the server restarts a client can resend the
request and continue from it left off
• Possible states of a server are also resources
and should be given their own URIs!
15
 REST Principle #2*
All interactions are context-free: each interaction
contains all of the information necessary to
understand the request, independent of any
requests that may have preceded it.

16
Understanding REST - Representations
• Resources are NOT data – they are an
abstraction of how the information/data is
split up for presentation/consumption
• The web server must respond to a request by
sending a series of bytes in a specific file
format, in a specific language – i.e. a
representation of the resource
– Formats: XML/JSON, HTML, PDF, PPT, DOCX...
– Languages: English, Spanish, Hindi, Portuguese…

17
Which Representation to Request?
• Style 1: Distinct URI for each representation:
– ex.com/press-release/2012-11.en (English)
– ex.com/press-release/2012.11.fr (French)
– …and so on
• Style 2: Content Negotiation
– Expose Platonic form URI:
• ex.com/press-release/2012-11
– Client sets specific HTTP request headers to signal
what representations it’s willing to accept
• Accept: Acceptable file formats
• Accept-Language: Preferred language
18
 REST Principle #3*
The representation of a resource is a sequence of
bytes, plus representation metadata to describe
those bytes. The particular form of the
representation can be negotiated between REST
components

19
Understanding REST – Uniform Interface
• HTTP Provides 4 basic methods for CRUD (Create,
Read, Update, Delete) operations:
– GET: Retrieve representation of resource
– PUT: Update/modify existing resource (or create a new
resource)
– POST: Create a new resource
– DELETE: Delete an existing resource
• Another 2 less commonly used methods:
– HEAD: Fetch meta-data of representation only (i.e. a
metadata representation)
– OPTIONS: Check which HTTP methods a particular
resource supports
20
 HTTP Methods
• Following four HTTP methods are commonly
used in REST based architecture.
• GET − Provides a read only access to a
resource.
• POST − Used to create a new resource.
• DELETE − Used to remove a resource.
• PUT − Used to update a existing resource or
create a new resource.

21
22
23
24
25
 PUT vs. POST
• POST
– Commonly used for creating subordinate resources
existing in relation to some ‘parent’ resource
• Parent: /weblogs/myweblog
• Children: /weblogs/myweblog/entries/1
• Parent: Table in DB; Child: Row in Table

• PUT
– Usually used for modifying existing resources
– May also be used for creating resources

26
 PUT vs. POST (Cont’d)
• What in case of partial updates or appending
new data? PUT or POST?
– PUT states: Send completely new representation
overwriting current one
– POST states: Create new resource
• In practice:
– PUT for partial updates works fine. No
evidence/claim for ‘why’ it can’t (or shouldn’t) be
used as such (personal preference)
– POST may also be used and some purists prefer
this
27
 REST Principle #4
Idempotent operations and representation
metadata are encouraged in support of caching
and representation reuse.

28
•Understanding
When correctly usedREST – Safety
GET and & Idempotence
HEAD requests are safe and
GET, HEAD, PUT, DELETE are idempotent. POST is neither
safe nor idempotent
• Safety: The request doesn’t change server state i.e. no
side effects  no changing state of resource
– Making 10 requests is same as making one or none at all
• Idempotence: Executing the same operation multiple
times is the same as executing it once
– Deleting an already DELETE-ed resource is still deleted
– Updating an already updated resource with PUT has no
effect
– https://restfulapi.net/idempotent-rest-apis/

29
An idempotent HTTP method is an HTTP method that can be called
many times without different outcomes. It would not matter if the
method is called only once, or ten times over. The result should be
the same.
Idempotence essentially means that the result of a successfully
performed request is independent of the number of times it is
executed. For example, in arithmetic, adding zero to a number is an
idempotent operation.

30
 HTTP Status/Response Codes
• HTTP is built in with a set of status codes for
various types of scenarios:
– 2xx Success (200 OK, 201 Created…)
– 3xx Redirection (303 See other)
– 4xx Client error (404 Not Found)
– 5xx Server error (500 Internal Server Errror)
• Leverage existing status codes to handle
sunny/rainy-day scenarios in your application!

31
 Points to Note
• Authentication/Authorization data sent with every
request
• Sessions are NOT RESTful (i.e. sessions = state)
• Cookies, if used appropriately (for storing client state)
are RESTful
• 100% RESTful architecture is not practical and not
valuable either
• Need to be unRESTful at times (Eg.: Login/Logout)
– These are actions and not a resource per se
– Usually POST requests sent to some URI for logging in/out
– Advantages: Gives login page, provides ability of “Forgot
your password” type functionalities etc.
– Benefits of UnRESTful-ness outweigh adherence to style

32
 Benefits of RESTful Design
• Simpler and intuitive design – easier navigability
• Server doesn’t have to worry about client timeout
• Clients can easily survive a server restart (state controlled
by client instead of server)
• Stateless applications are easier to cache – applications can
decide which response to cache without worrying about
‘state’ of a previous request
• Bookmark-able URIs/Application States
• HTTP is stateless by default – developing applications
around it gets above benefits

33
34
35