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

1. Gran Sasso Science Institute
Ivano Malavolta
REST

2. Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security

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)

4. Major players

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

8. REST Overview
http://bit.ly/JALve1
In most cases,
client-server
comunication
relies on HTTP

9. REST Main Actors
These are the abstractions that make a RESTful system:
• Resources
• Representations
• Actions

10. Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security

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

15. URIs
URIs and URLs are also used to link resources together
ex.

16. Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security

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

23. Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security

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

30. The Classroom Example: Representations
Student:
<student>
<name>Jane</name>
<age>10</age>
<link>/students/Jane</link>
</student>

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

33. GET Example

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

35. POST Example

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

37. PUT Example
The initial GET
is omitted here

38. DELETE
The method DELETE is used to DELETE resources
Similarly to PUT, also in this case we need the URI of the resource
being deleted

39. DELETE Example

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

42. Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security

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

50. Example of Request
<input type="text" name=“u" id=“u" value="" />
<input type="password" name=“p" id=“p" value="" />
var username = $('#u').val();
var password = MD5($('#p').val());
$.ajax({
type: 'POST',
url: ‘https://www.domain.com/login.php',
data: {
username: username,
password: password
},
success: function(result) {
console.log(“logged in”);
}
});

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

53. OAuth
Your
app
Service
provider
User

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

57. Intuition behind OAuth
http://en.wikipedia.org/wiki/OAuth

58. OAuth 2.0 Authentication flow
your
app
Auth Server
(ex. Facebook)
user

59. More formally...
http://goo.gl/rNm80

60. References
http://bit.ly/JA1UPT
Cordova Facebook plugin:
http://goo.gl/7qY54
Facebook login without plugin:
http://github.com/ccoenraets/OpenFB

61. + 39 380 70 21 600
Contact
Ivano Malavolta |
Gran Sasso Science Institute
iivanoo
ivano.malavolta@univaq.it
www.ivanomalavolta.com