Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Mobile applications Development - Lecture 14

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).

http://www.di.univaq.it/malavolta

Ivano Malavolta

May 17, 2012
Tweet

More Decks by Ivano Malavolta

Other Decks in Technology

Transcript

  1. REST
    Ivano Malavolta
    Ivano Malavolta
    [email protected]
    http://www.di.univaq.it/malavolta

    View Slide

  2. Roadmap
    • The REST Architectural Style
    • Resources
    • Resources
    • Representations
    • Actions
    • Security

    View Slide

  3. REST
    It stands for
    REpresentational State Transfer
    Proposed by Roy Fieldings
    in his PhD dissertation in 2000
    in his PhD dissertation in 2000
    REST rules the architecture of
    the World Wide Web (HTTP)

    View Slide

  4. Major players

    View Slide

  5. REST Architectural Style
    REST is not a technology, nor a framework
    REST is an Architectural
    Architectural
    Architectural
    Architectural Style
    Style
    Style
    Style
    a set of principles + constraints
    Thos constraints help us in developing applications
    Thos constraints help us in developing applications
    that are “easy” to maintain and extend

    View Slide

  6. REST Main Constraints
    A RESTful system should be
    • client
    client
    client
    client-
    -
    -
    -server
    server
    server
    server
    • stateless
    stateless
    stateless
    stateless
    – there should be no need for the service to keep users’
    sessions
    – each request should be independent of others
    – each request should be independent of others
    • it has to support a caching system
    caching system
    caching system
    caching system
    • it has to be uniformly accessible
    uniformly accessible
    uniformly accessible
    uniformly accessible
    – each resource must have a unique address and a valid
    point of access

    View Slide

  7. The (static) Web as a RESTful system
    1. you type a URL into your browser to reach a
    specific HTML page
    specific HTML page
    2. the browser gets and displays the elements of the
    HTML page
    the browser is getting a representation
    representation
    representation
    representation
    the browser is getting a representation
    representation
    representation
    representation
    of the current state of that resource
    resource
    resource
    resource

    View Slide

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

    View Slide

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

    View Slide

  10. Roadmap
    • The REST Architectural Style
    • Resources
    • Resources
    • Representations
    • Actions
    • Security

    View Slide

  11. Resources
    A
    A
    A
    A resource
    resource
    resource
    resource is
    is
    is
    is “


    “everything
    everything
    everything
    everything” the service can
    ” the service can
    ” the service can
    ” the service can provide
    provide
    provide
    provide
    States and functions of a remote application are also
    States and functions of a remote application are also
    States and functions of a remote application are also
    States and functions of a remote application are also
    considered as resources
    considered as resources
    considered as resources
    considered as resources
    Example of resources:
    • title of a movie from IMDb
    • a Flash movie from YouTube
    • a Flash movie from YouTube
    • images from Flickr
    • order info from eBay
    • etc.

    View Slide

  12. Resources
    In general, a RESTful resource is anything that is
    anything that is
    anything that is
    anything that is
    addressable over the Web
    addressable over the Web
    addressable over the Web
    addressable over the Web
    addressable over the Web
    addressable over the Web
    addressable over the Web
    addressable over the Web
    Addressable
    Addressable
    Addressable
    Addressable =
    =
    =
    = anything that can be accessed and
    transferred between clients and servers
    a resource must have a unique address over the Web
    a resource must have a unique address over the Web
    Under HTTP these are URIs
    URIs
    URIs
    URIs

    View Slide

  13. URIs
    Uniform Resource Identifier
    Uniform Resource Identifier
    Uniform Resource Identifier
    Uniform Resource Identifier
    in a RESTful web service is a hyperlink
    hyperlink
    hyperlink
    hyperlink to a resource
    It is the only means for clients and servers to exchange
    representations of resources
    ex.
    .../orderinfo?id=123

    View Slide

  14. URIs
    The URI is not meant to change over time
    The URI is not meant to change over time
    The URI is not meant to change over time
    The URI is not meant to change over time
    it is the only means to locate a specific resource
    it is the only means to locate a specific resource
    URIs are also used to negotiate representations of a given
    resource
    In the url you give certain parameters
    parameters
    parameters
    parameters that define which
    information you want the server to return to you (just
    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

    View Slide

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

    View Slide

  16. Roadmap
    • The REST Architectural Style
    • Resources
    • Resources
    • Representations
    • Actions
    • Security

    View Slide

  17. Representations
    The representation
    representation
    representation
    representation of resources is what is sent back
    and forth between clients and servers
    and forth between clients and servers
    So, we never send or receive resources, only their
    we never send or receive resources, only their
    we never send or receive resources, only their
    we never send or receive resources, only their
    representations
    representations
    representations
    representations

    View Slide

  18. URL
    Uniform Resource Locator
    Uniform Resource Locator
    Uniform Resource Locator
    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

    View Slide

  19. Representations
    The format of the representation is determined by the
    content
    content
    content
    content-
    -
    -
    -type
    type
    type
    type
    content
    content
    content
    content-
    -
    -
    -type
    type
    type
    type
    The interaction of the representation on the resource
    is determined by the action (GET, SET, etc.)

    View Slide

  20. Content-types
    Since we are using HTTP to communicate, we can transfer
    any kind of information that can be passed between
    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
    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

    View Slide

  21. Representation Formats
    Different clients are able to consume different
    representations of the same resource
    A representation can take various forms
    A representation can take various forms
    A representation can take various forms
    A representation can take various forms, such as:
    • image
    • a text file
    • an XML stream
    • an XML stream
    • a JSON stream
    but its resource has to be available through the same
    but its resource has to be available through the same
    but its resource has to be available through the same
    but its resource has to be available through the same
    URI
    URI
    URI
    URI

    View Slide

  22. Representation Formats
    For human-generated requests through a web browser,
    a representation is typically in the form of an HTML
    a representation is typically in the form of an HTML
    page
    For automated requests from other web services,
    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
    XML or JSON
    XML or JSON
    XML or JSON

    View Slide

  23. Roadmap
    • The REST Architectural Style
    • Resources
    • Resources
    • Representations
    • Actions
    • Security

    View Slide

  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

    View Slide

  25. HTTP-based Actions
    Under HTTP, actions are standard HTTP request:
    GET
    GET
    GET
    GET
    POST
    POST
    POST
    POST
    PUT
    PUT
    PUT
    PUT
    DELETE
    DELETE
    DELETE
    DELETE
    DELETE
    DELETE
    DELETE
    DELETE
    They make up the uniform interface used for
    client/server data transfers

    View Slide

  26. HTTP-based Actions
    RESTful web services can also execute logic at the
    server level, but remembering that every result
    every result
    every result
    every result
    must be a resource representation
    must be a resource representation
    must be a resource representation
    must be a resource representation

    View Slide

  27. HTTP as Uniform Interface
    In
    In
    In
    In RESTful
    RESTful
    RESTful
    RESTful systems
    systems
    systems
    systems we
    we
    we
    we focus on
    focus on
    focus on
    focus on resource
    resource
    resource
    resource names
    names
    names
    names, whereas
    in traditional web systems we focussed on the actions to
    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,
    Create, Retrieve, Update,
    Create, Retrieve, Update,
    Create, Retrieve, Update,
    and Delete (CRUD)
    and Delete (CRUD)
    and Delete (CRUD)
    and Delete (CRUD)
    and Delete (CRUD)
    and Delete (CRUD)
    and Delete (CRUD)
    and Delete (CRUD)
    In traditional web applications, we could have countless
    actions with no naming or implementation standards

    View Slide

  28. The Classroom Example
    Artificial example of a web service handling students
    in some classroom
    in some classroom
    Location of the service = http://restfuljava.com/
    Resources are represented as XML streams

    View Slide

  29. The Classroom Example: URIs
    Student (identified by name):
    http://restfuljava.com/students/{name}
    http://restfuljava.com/students/{name}
    List of students:
    http://restfuljava.com/students

    View Slide

  30. The Classroom Example: Representations
    Student:

    Jane
    10
    /students/Jane


    View Slide

  31. The Classroom Example: Representations
    Students List:


    Jane
    10
    /students/Jane



    John
    11
    /students/John


    View Slide

  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

    View Slide

  33. GET Example

    View Slide

  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

    View Slide

  35. POST Example

    View Slide

  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)
    value(s)
    3. we update the resource using a PUT request
    together with the representation as its payload

    View Slide

  37. PUT Example
    The initial
    GET is
    omitted here

    View Slide

  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

    View Slide

  39. DELETE Example

    View Slide

  40. A note on PUT and DELETE
    PUT and DELETE apply to the entire resource
    PUT and DELETE apply to the entire resource
    PUT and DELETE apply to the entire resource
    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
    The PUT and DELETE operations are atomic
    The PUT and DELETE operations are atomic
    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

    View Slide

  41. HTTP Status Codes
    RESTful services use these codes to return information
    about the response of the requests
    about the response of the requests
    1xx informational message
    2xx success message
    3xx redirects the client to another URL
    4xx client-side error
    4xx client-side error
    5xx server-side error

    View Slide

  42. Roadmap
    • The REST Architectural Style
    • Resources
    • Resources
    • Representations
    • Actions
    • Security

    View Slide

  43. Security
    Here we will focus on securing user access to our
    services
    services
    There are three main methods:
    1.
    1.
    1.
    1. Custom
    Custom
    Custom
    Custom token
    token
    token
    token authentication
    authentication
    authentication
    authentication
    Control access
    2.
    2.
    2.
    2. HTTP
    HTTP
    HTTP
    HTTP Basic
    Basic
    Basic
    Basic authentication
    authentication
    authentication
    authentication
    3.
    3.
    3.
    3. OAuth
    OAuth
    OAuth
    OAuth
    Control access
    to resources
    Accessing services
    on behalf of users

    View Slide

  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.

    View Slide

  45. Pros and Cons
    +
    +
    +
    + The generation of an access token is independent
    The generation of an access token is independent
    The generation of an access token is independent
    The generation of an access token is independent
    of the web service
    of the web service
    of the web service
    of the web service
    of the web service
    of the web service
    of the web service
    of the web service
    +
    +
    +
    + It is a simple approach
    It is a simple approach
    It is a simple approach
    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
    data exchange can be logged and verified
    data exchange can be logged and verified
    data exchange can be logged and verified
    +
    +
    +
    + data exchange can be logged and verified
    data exchange can be logged and verified
    data exchange can be logged and verified
    data exchange can be logged and verified
    – since access is controlled for each request
    - This
    This
    This
    This method
    method
    method
    method is
    is
    is
    is not
    not
    not
    not secure
    secure
    secure
    secure
    – The passed token can be copied and reused without
    authorization

    View Slide

  46. How to send the token?
    The authentication token is sent with every request in
    two ways:
    two ways:
    1. it can be part of the URI
    2. it can be added to the HTTP request header

    View Slide

  47. HTTP Basic authentication
    The client sends the (cleartext Base64 encoded)
    username and password pair in the HTTP header
    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

    View Slide

  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
    + this potential security hole can be solved by using
    HTTPS (SSL)

    View Slide

  49. Client/server transaction
    It can take 2 forms:
    1. a client makes a request to the server without
    without
    without
    without
    authentication credentials
    authentication credentials
    authentication credentials
    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
    then provide valid credentials to complete the original
    request
    2. a client makes a request to the server with
    server with
    server with
    server with
    authentication credentials from the beginning
    authentication credentials from the beginning
    authentication credentials from the beginning
    authentication credentials from the beginning

    View Slide

  50. Example of Request


    var username = $('#u').val();
    var password = MD5($('#p').val());
    $.ajax({
    type: 'POST',
    url: ‘https://www.domain.com/login.php',
    data: {
    username: username,
    username: username,
    password: password
    },
    success: function(result) {
    console.log(“logged in”);
    }
    });

    View Slide

  51. Oauth 2.0
    OAuth's authorization protocol is becoming the
    preferred authorization scheme
    preferred authorization scheme
    It is simple
    simple
    simple
    simple and easy to
    easy to
    easy to
    easy to
    integrate to
    integrate to
    integrate to
    integrate to RESTful
    RESTful
    RESTful
    RESTful services
    services
    services
    services
    Open source
    pen source
    pen source
    pen source protocol

    View Slide

  52. What are we talking about...
    http://slidesha.re/JdfBGy

    View Slide

  53. OAuth
    your Service
    your
    app
    Service
    provider

    View Slide

  54. OAuth 2.0
    It is used for accessing web services on the behalf of
    the user
    the user
    OAuth
    OAuth
    OAuth
    OAuth is an authorization protocol that allows
    is an authorization protocol that allows
    is an authorization protocol that allows
    is an authorization protocol that allows
    third
    third
    third
    third-
    -
    -
    -party web service creators (you) to get
    party web service creators (you) to get
    party web service creators (you) to get
    party web service creators (you) to get
    access to users' data stored in a different web
    access to users' data stored in a different web
    access to users' data stored in a different web
    access to users' data stored in a different web
    service
    service
    service
    service
    This can happen only with users' consent and without a
    username and password exchange

    View Slide

  55. OAuth 2.0
    Before OAuth, users needed to pass login information
    to multiple third party services
    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

    View Slide

  56. OAuth Basics
    Authentication
    Authentication
    Authentication
    Authentication
    • Need to log in to access parts of a website
    • Need to log in to access parts of a website
    – ex: view user profile
    – post a photo
    – add a friend
    – view private messages
    Token
    Token
    Token
    Token-
    -
    -
    -based Authentication
    based Authentication
    based Authentication
    based Authentication
    • Logged-in user has a unique token
    unique token
    unique token
    unique token used to access
    data from your app

    View Slide

  57. Intuition behind OAuth

    View Slide

  58. OAuth 2.0 Authentication flow
    the
    user
    your
    app
    app
    Auth Server
    (ex. Facebook)
    http://tools.ietf.org/html/draft-ietf-oauth-v2-26
    The server hosting
    protected resources
    (ex. Facebook)

    View Slide

  59. Example: Google+

    View Slide

  60. References
    http://bit.ly/JA1UPT
    Cordova plugin for FB:
    http://bit.ly/JdjoUh

    View Slide