REST Basics


Published on

Mobile applications Development - Lecture 14

REST Basics

This presentation has been developed in the context of the Mobile Applications Development course at the Computer Science Department of the University of L’Aquila (Italy).

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

REST Basics

  1. 1. REST Ivano Malavolta ivano.malavolta@univaq.it
  2. 2. Roadmap• The REST Architectural Style• Resources• Representations• Actions• Security
  3. 3. RESTIt stands forREpresentational State TransferProposed by Roy Fieldingsin his PhD dissertation in 2000REST rules the architecture ofthe World Wide Web (HTTP)
  4. 4. Major players
  5. 5. REST Architectural StyleREST is not a technology, nor a frameworkREST is an Architectural Style a set of principles + constraintsThos constraints help us in developing applications that are “easy” to maintain and extend
  6. 6. REST Main ConstraintsA RESTful system should be client-• 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 system1. you type a URL into your browser to reach a specific HTML page2. 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 In most cases, client-server comunication relies on HTTP
  9. 9. REST Main ActorsThese are the abstractions that make a RESTful system:• Resources• Representations• Actions
  10. 10. Roadmap• The REST Architectural Style• Resources• Representations• Actions• Security
  11. 11. ResourcesA resource is “everything” the service can provide everything”States and functions of a remote application are also considered as resourcesExample of resources:• title of a movie from IMDb• a Flash movie from YouTube• images from Flickr• order info from eBay• etc.
  12. 12. ResourcesIn general, a RESTful resource is anything that is addressable over the WebAddressable = anything that can be accessed and transferred between clients and servers a resource must have a unique address over the Web Under HTTP these are URIs
  13. 13. URIs Uniform Resource Identifierin a RESTful web service is a hyperlink to a resourceIt is the only means for clients and servers to exchange representations of resources ex. .../orderinfo?id=123
  14. 14. URIsThe URI is not meant to change over time it is the only means to locate a specific resourceURIs are also used to negotiate representations of a given resourceIn the url 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 you with a resource representation containing the information you’ve asked
  15. 15. URIsURIs are also used to link resources togetherex.
  16. 16. Roadmap• The REST Architectural Style• Resources• Representations• Actions• Security
  17. 17. RepresentationsThe representation of resources is what is sent back and forth between clients and serversSo, we never send or receive resources, only their representations
  18. 18. URL Uniform Resource LocatorA URL is a specialization of URI that defines the network location of a specific resourceUnlike a URI, the URL defines how the resource can be obtained es.
  19. 19. RepresentationsThe format of the representation is determined by the content- content-typeThe interaction of the representation on the resource is determined by the action (GET, SET, etc.)
  20. 20. Content-typesSince we are using HTTP to communicate, we can transfer any kind of information that can be passed between clients and serversex. 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 FormatsDifferent clients are able to consume different representations of the same resourceA representation can take various forms such as: forms,• image• a text file• an XML stream• a JSON streambut its resource has to be available through the same URI
  22. 22. Representation FormatsFor human-generated requests through a web browser, a representation is typically in the form of an HTML pageFor 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. ActionsActions are used to operate on resourcesFor example, they can be used for – getting info about a movie – adding a photo to Flickr – deleting a file from a folderThe data transmitted to and from the resource is a representation of it
  25. 25. HTTP-based ActionsUnder HTTP, actions are standard HTTP request: GET POST PUT DELETEThey make up the uniform interface used for client/server data transfers
  26. 26. HTTP-based ActionsRESTful web services can also execute logic at the server level, but remembering that every result must be a resource representation
  27. 27. HTTP as Uniform InterfaceIn RESTful systems we focus on resource names whereas names, 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 ExampleArtificial example of a web service handling students in some classroomLocation of the service = are represented as XML streams
  29. 29. The Classroom Example: URIsStudent (identified by name):{name}List of students:
  30. 30. The Classroom Example: RepresentationsStudent:<student> <name>Jane</name> <age>10</age> <link>/students/Jane</link></student>
  31. 31. The Classroom Example: RepresentationsStudents 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. GETThe method GET is used to RETRIEVE resourcesIt cannot have side-effects it can be done repeatedly without changing the state of the resourceIt 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. POSTThe method POST is used to CREATE resourcesUsually, 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. PUTThe method PUT is used to UPDATE resourcesRecurrent PUT workflow:1. we first GET the representation of the resource we need to update2. 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 isomitted here
  38. 38. DELETEThe method DELETE is used to DELETE resourcesSimilarly 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 DELETEPUT and DELETE apply to the entire resource when doing a PUT or DELETE operation, the entire resource is replaced/deletedThe 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 CodesRESTful 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. SecurityHere we will focus on securing user access to our servicesThere are three main methods:1. Custom token authentication Control access to resources2. HTTP Basic authentication Accessing services3. OAuth on behalf of users
  44. 44. Custom Token Authentication2-steps process1. The server generates a unique token for a registered API user2. The registered user sends the generated token for authentication with every request to the serviceThe 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 accountAccess+ 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 URI2. 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
  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 transactionIt 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 request2. 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: ‘, data: { username: username, password: password }, success: function(result) { console.log(“logged in”); }});
  51. 51. Oauth 2.0OAuths authorization protocol is becoming the preferred authorization schemeIt is simple and easy tointegrate to RESTful servicesOpen source protocol pen
  52. 52. What are we talking about...
  53. 53. OAuthyour Serviceapp provider
  54. 54. OAuth 2.0It is used for accessing web services on the behalf of the userOAuth is an authorization protocol that allows third- third-party web service creators (you) to get access to users data stored in a different web serviceThis can happen only with users consent and without a username and password exchange
  55. 55. OAuth 2.0Before OAuth, users needed to pass login information to multiple third party servicesWith 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 BasicsAuthentication• Need to log in to access parts of a website – ex: view user profile – post a photo – add a friend – view private messagesToken-Token-based Authentication• Logged-in user has a unique token used to access data from your app
  57. 57. Intuition behind OAuth
  58. 58. OAuth 2.0 Authentication flow the user your app Auth Server (ex. Facebook) The server hosting protected resources (ex. Facebook)
  59. 59. Example: Google+
  60. 60. References plugin for FB: