0
Gran Sasso Science Institute
Ivano Malavolta
REST
Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security
REST
It stands for

REpresentational 
State Transfer


Proposed by Roy Fieldings
in his PhD dissertation in 2000

REST rul...
Major players
REST Architectural Style
REST is not a technology, nor a framework

REST is an Architectural Style 
à  a set of principle...
REST Main Constraints
A RESTful system should be

•  client-server
•  stateless
–  there should be no need for the service...
The (static) Web as a RESTful system
1.  you type a URL into your browser to reach a specific HTML
page
2.  the browser get...
REST Overview 
http://bit.ly/JALve1
In most cases,
client-server
comunication
relies on HTTP
REST Main Actors
These are the abstractions that make a RESTful system:

•  Resources
•  Representations
•  Actions
Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security
Resources
A resource is “everything” the service can provide

States and functions of a remote application are also consid...
Resources
In general, a RESTful resource is anything that is addressable 
over the Web

Addressable = anything that can be...
URIs
Uniform Resource Identifier

in a RESTful web service is a hyperlink to a resource

It is the only means for clients a...
URIs
The URI is not meant to change over time
à it is the only means to identify a specific resource 

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

ex.
Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security
Representations
The representation of resources is what is sent back and forth
between clients and servers

So, we never s...
URL
Uniform Resource Locator

A URL is a specialization of URI that defines the network location
of a specific resource

Unl...
Representations
The format of the representation is determined by the content-
type 

The interaction of the representatio...
Content-types
Since we are using HTTP to communicate, we can transfer any
kind of information that can be passed between c...
Representation Formats
Different clients are able to consume different representations
of the same resource

A representat...
Representation Formats
For human-generated requests through a web browser, a
representation is typically in the form of an...
Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security
Actions
Actions are used to operate on resources

For example, they can be used for
–  getting info about a movie
–  addin...
HTTP-based Actions
Under HTTP, actions are standard HTTP request:

GET
POST
PUT
DELETE

They make up the uniform interface...
HTTP-based Actions
RESTful web services can also execute logic at the server level,
but remember that every result must be...
HTTP as Uniform Interface
In RESTful systems we focus on resource names, whereas in
traditional web systems we focussed on...
The Classroom Example
Artificial example of a web service handling students in some
classroom

Location of the service = ht...
The Classroom Example: URIs
Student (identified by name):

http://restfuljava.com/students/{name}

List of students: 
http:...
The Classroom Example: Representations
Student:
<student>
<name>Jane</name>
<age>10</age>
<link>/students/Jane</link>
</st...
The Classroom Example: Representations
Students List:
<students>
<student>
<name>Jane</name>
<age>10</age>
<link>/students...
GET
The method GET is used to RETRIEVE resources

It cannot have side-effects
à it can be done repeatedly without changin...
GET Example
POST
The method POST is used to CREATE resources


Usually, the resource identity/URL is not known at creation time

à Th...
POST Example
PUT
The method PUT is used to UPDATE resources

Recurrent PUT workflow:
1.  we first GET the representation of the resource ...
PUT Example
The initial GET
is omitted here
DELETE
The method DELETE is used to DELETE resources

Similarly to PUT, also in this case we need the URI of the resource
...
DELETE Example
A note on PUT and DELETE
PUT and DELETE apply to the entire resource


à 
when doing a PUT or DELETE operation, 


the en...
HTTP Status Codes
RESTful services use these codes to return information about the
response of the requests

1xx 

informa...
Roadmap
The REST Architectural Style
Resources
Representations
Actions
Security
Security
Here we will focus on securing user access to our services

There are three main methods:

1.  Custom token authe...
Custom Token Authentication
2-steps process

1.  The server generates a unique token for a registered API
user
2.  The reg...
Pros and Cons
+ 
The generation of an access token is independent of the web
service 

+ 
It is a simple approach
–  while...
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...
HTTP Basic authentication
The client sends the (cleartext Base64 encoded) username and
password pair in the HTTP header Au...
Pros and Cons
+ 
clients must manage server authorization requests

-  in general, it is not secure
-  because usernames a...
Client/server transaction
It can take 2 forms:

1.  a client makes a request to the server without authentication
credenti...
Example of Request
<input type="text" name=“u" id=“u" value="" />
<input type="password" name=“p" id=“p" value="" />
var u...
Oauth 2.0
OAuth's authorization protocol is becoming the preferred
authorization scheme

It is simple and easy to 
integra...
What are we talking about...
http://slidesha.re/JdfBGy
OAuth
Your
app
Service
provider
User
OAuth 2.0
It is used for accessing web services on the behalf of the user

OAuth is an authorization protocol that allows ...
OAuth 2.0
Before OAuth, users needed to pass login information to multiple
third party services

With OAuth, users don’t d...
OAuth Basics 
Authentication
•  Need to log in to access parts of a website
–  ex: view user profile
–  post a photo
–  add...
Intuition behind OAuth
http://en.wikipedia.org/wiki/OAuth
OAuth 2.0 Authentication flow
your
app
 Auth Server
(ex. Facebook)
user
More formally...
http://goo.gl/rNm80
References



http://bit.ly/JA1UPT


Cordova Facebook plugin:


http://goo.gl/7qY54

Facebook login without plugin:


http...
+ 39 380 70 21 600
Contact
Ivano Malavolta | 
Gran Sasso Science Institute
iivanoo
ivano.malavolta@univaq.it
www.ivanomala...
Upcoming SlideShare
Loading in...5
×

Rest

541

Published on

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
541
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
35
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Rest "

  1. 1. Gran Sasso Science Institute Ivano Malavolta REST
  2. 2. Roadmap The REST Architectural Style Resources Representations Actions Security
  3. 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. 4. Major players
  5. 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. 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. 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. 8. REST Overview http://bit.ly/JALve1 In most cases, client-server comunication relies on HTTP
  9. 9. REST Main Actors These are the abstractions that make a RESTful system: •  Resources •  Representations •  Actions
  10. 10. Roadmap The REST Architectural Style Resources Representations Actions Security
  11. 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. 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. 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. 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. 15. URIs URIs and URLs are also used to link resources together ex.
  16. 16. Roadmap The REST Architectural Style Resources Representations Actions Security
  17. 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. 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. 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. 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. 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. 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. 23. Roadmap The REST Architectural Style Resources Representations Actions Security
  24. 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. 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. 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. 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. 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. 29. The Classroom Example: URIs Student (identified by name): http://restfuljava.com/students/{name} List of students: http://restfuljava.com/students
  30. 30. The Classroom Example: Representations Student: <student> <name>Jane</name> <age>10</age> <link>/students/Jane</link> </student>
  31. 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. 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. 33. GET Example
  34. 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. 35. POST Example
  36. 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. 37. PUT Example The initial GET is omitted here
  38. 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. 39. DELETE Example
  40. 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. 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. 42. Roadmap The REST Architectural Style Resources Representations Actions Security
  43. 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. 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. 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. 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. 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. 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. 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. 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. 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. 52. What are we talking about... http://slidesha.re/JdfBGy
  53. 53. OAuth Your app Service provider User
  54. 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. 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. 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. 57. Intuition behind OAuth http://en.wikipedia.org/wiki/OAuth
  58. 58. OAuth 2.0 Authentication flow your app Auth Server (ex. Facebook) user
  59. 59. More formally... http://goo.gl/rNm80
  60. 60. References http://bit.ly/JA1UPT Cordova Facebook plugin: http://goo.gl/7qY54 Facebook login without plugin: http://github.com/ccoenraets/OpenFB
  61. 61. + 39 380 70 21 600 Contact Ivano Malavolta | Gran Sasso Science Institute iivanoo ivano.malavolta@univaq.it www.ivanomalavolta.com
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×