The REST Architectural Style
Resources
Representations
Actions
Security
This presentation has been developed in the context of the Mobile Applications Development course, DISIM, University of L'Aquila (Italy), Spring 2014.
http://www.ivanomalavolta.com
3. REST
It stands for
REpresentational
State Transfer
Proposed by Roy Fieldings
in his PhD dissertation in 2000
REST rules the architecture of
the World Wide Web (HTTP)
5. REST Architectural Style
REST is not a technology, nor a framework
REST is an Architectural Style
à a set of principles + constraints
Those constraints help us in developing applications that are
“easy” to maintain and extend
6. REST Main Constraints
A RESTful system should be
• client-server
• stateless
– there should be no need for the service to keep users’
sessions
– each request should be independent of others
• it has to support a caching system
• it has to be uniformly accessible
– each resource must have a unique address and a valid point
of access
7. The (static) Web as a RESTful system
1. you type a URL into your browser to reach a specific HTML
page
2. the browser gets and displays the elements of the HTML page
à
the browser is getting a representation of the current state
of that resource
11. Resources
A resource is “everything” the service can provide
States and functions of a remote application are also considered
as resources
Example of resources:
• title of a movie from IMDb
• a Flash movie from YouTube
• images from Flickr
• order info from eBay
• etc.
12. Resources
In general, a RESTful resource is anything that is addressable
over the Web
Addressable = anything that can be accessed and transferred
between client and server
à a resource must have a unique address over the Web
Under HTTP these are URIs
13. URIs
Uniform Resource Identifier
in a RESTful web service is a hyperlink to a resource
It is the only means for clients and servers to exchange
representations of resources
ex.
.../orderinfo?id=123
14. URIs
The URI is not meant to change over time
à it is the only means to identify a specific resource
URIs are also used to negotiate representations of a given
resource
In the URI you give certain parameters that define which
information you want the server to return to you (just like
giving GET variables to a page)
The server will respond with a resource representation
containing the information you’ve asked
17. Representations
The representation of resources is what is sent back and forth
between clients and servers
So, we never send or receive resources, only their representations
18. URL
Uniform Resource Locator
A URL is a specialization of URI that defines the network location
of a specific resource
Unlike a URI, the URL defines how the resource can be obtained
es.
http://some.domain.com/orderinfo?id=123
19. Representations
The format of the representation is determined by the content-
type
The interaction of the representation on the resource is
determined by the action (GET, SET, etc.)
20. Content-types
Since we are using HTTP to communicate, we can transfer any
kind of information that can be passed between clients and
servers
ex. text files, PDF documents, images, videos, etc.
In any case, the data is streamed over TCP/IP and the browser
knows how to interpret the binary streams because of the
HTTP protocol response header Content-Type
21. Representation Formats
Different clients are able to consume different representations
of the same resource
A representation can take various forms, such as:
• image
• a text file
• an XML stream
• a JSON stream
but its resource has to be available through the same URI
22. Representation Formats
For human-generated requests through a web browser, a
representation is typically in the form of an HTML page
For automated requests from other web services, readability is
not as important and a more efficient representation can be
used such as XML or JSON
24. Actions
Actions are used to operate on resources
For example, they can be used for
– getting info about a movie
– adding a photo to Flickr
– deleting a file from a folder
The data transmitted to and from the resource is a representation
of it
25. HTTP-based Actions
Under HTTP, actions are standard HTTP request:
GET
POST
PUT
DELETE
They make up the uniform interface used for client/server data
transfers
26. HTTP-based Actions
RESTful web services can also execute logic at the server level,
but remember that every result must be a resource
representation
27. HTTP as Uniform Interface
In RESTful systems we focus on resource names, whereas in
traditional web systems we focussed on the actions to be
performed on resources
à In RESTful systems we have four specific actions that we can
take upon resources — Create, Retrieve, Update, and Delete
(CRUD)
In traditional web applications, we could have countless actions
with no naming or implementation standards
28. The Classroom Example
Artificial example of a web service handling students in some
classroom
Location of the service = http://restfuljava.com/
Resources are represented as XML streams
29. The Classroom Example: URIs
Student (identified by name):
http://restfuljava.com/students/{name}
List of students:
http://restfuljava.com/students
31. The Classroom Example: Representations
Students List:
<students>
<student>
<name>Jane</name>
<age>10</age>
<link>/students/Jane</link>
</student>
<student>
<name>John</name>
<age>11</age>
<link>/students/John</link>
</student>
</students>
32. GET
The method GET is used to RETRIEVE resources
It cannot have side-effects
à it can be done repeatedly without changing the state of the
resource
It can also return only parts of the resource
à it can act as both a read operation and a query operation
34. POST
The method POST is used to CREATE resources
Usually, the resource identity/URL is not known at creation time
à The URL of the newly created resource is usually created
automatically by the server
36. PUT
The method PUT is used to UPDATE resources
Recurrent PUT workflow:
1. we first GET the representation of the resource we need to
update
2. in the client we update the resource with the new value(s)
3. we update the resource using a PUT request together with
the representation as its payload
40. A note on PUT and DELETE
PUT and DELETE apply to the entire resource
à
when doing a PUT or DELETE operation,
the entire resource is replaced/deleted
The PUT and DELETE operations are atomic
à
if two PUT/DELETE operations occur simultaneously,
one of them will win and determine the final state of
the resource
41. HTTP Status Codes
RESTful services use these codes to return information about the
response of the requests
1xx
informational message
2xx
success message
3xx
redirects the client to another URL
4xx
client-side error
5xx
server-side error
43. Security
Here we will focus on securing user access to our services
There are three main methods:
1. Custom token authentication
2. HTTP Basic authentication
3. OAuth
Control access
to resources
Accessing services on
behalf of users
44. Custom Token Authentication
2-steps process
1. The server generates a unique token for a registered API
user
2. The registered user sends the generated token for
authentication with every request to the service
The token can be used to
• enable a specific user
• to check if traffic limits have been exceeded
• etc.
45. Pros and Cons
+
The generation of an access token is independent of the web
service
+
It is a simple approach
– while creating a user registration process, the server generates a
unique token per account access
+
data exchange can be logged and verified
– since access is controlled for each request
- This method is not secure
– The passed token can be copied and reused without authorization
46. How to send the token?
The authentication token is sent with every request in two ways:
1. it can be part of the URI
2. it can be added to the HTTP request header
47. HTTP Basic authentication
The client sends the (cleartext Base64 encoded) username and
password pair in the HTTP header Authorization
Username and password must be sent for every HTTP request
for the authorization to be validated
http://bit.ly/JFGCQW
48. Pros and Cons
+
clients must manage server authorization requests
- in general, it is not secure
- because usernames and passwords are only encoded using Base64
encoding, which can be easily deciphered
+
this potential security hole can be solved by using HTTPS (SSL)
49. Client/server transaction
It can take 2 forms:
1. a client makes a request to the server without authentication
credentials
– the server sends a response with an HTTP error code of 401
(unauthorized access)
– we need to programmatically intercept the 401 response and then
provide valid credentials to complete the original request
2. a client makes a request to the server with authentication
credentials from the beginning
51. Oauth 2.0
OAuth's authorization protocol is becoming the preferred
authorization scheme
It is simple and easy to
integrate to RESTful services
Open-source protocol
52. What are we talking about...
http://slidesha.re/JdfBGy
54. OAuth 2.0
It is used for accessing web services on the behalf of the user
OAuth is an authorization protocol that allows third-party web
service creators (you) to get access to users' data stored in a
different web service
This can happen only with users' consent and without a username
and password exchange
55. OAuth 2.0
Before OAuth, users needed to pass login information to multiple
third party services
With OAuth, users don’t divulge their login information
à authorization is granted from the provider service, where both
user’s data and credentials are stored
à the consumer service only receives an authorization token that
is used to access data from the provider service
56. OAuth Basics
Authentication
• Need to log in to access parts of a website
– ex: view user profile
– post a photo
– add a friend
– view private messages
Token-based Authentication
• Logged-in user has a unique token used to access data from
your app