Rest introduction

2,949 views

Published on

A quick introduction to REST based on Roy T Fielding dissertation.

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

  • Be the first to like this

No Downloads
Views
Total views
2,949
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
  • Visibility is improved because a monitoring system does not have to look beyond a single request datum in order to determine the full nature of the request. Reliability is improved because it eases the task of recovering from partial failures. Scalability is improved because not having to store state between requests allows the server component to quickly free resources, and further simplifies implementation because the server doesn't have to manage resource usage across requests.
  • Rest introduction

    1. 1. REST Prof. William Martínez Pomares
    2. 2. Agenda <ul><li>Basic Concepts </li></ul><ul><li>Constrains or Sub Styles </li></ul><ul><li>About Resources </li></ul><ul><li>REST and Services </li></ul>
    3. 3. REST <ul><li>Roy Fielding described REST as an architecture style which attempts “to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations&quot; </li></ul>Roy T Fielding. REST Disseration at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
    4. 4. REST <ul><li>Separation of resource from representation </li></ul><ul><li>Manipulation of resources by representations </li></ul><ul><li>Self-descriptive messages </li></ul><ul><li>Hypermedia as the engine of application state (HATEOAS). </li></ul>
    5. 5. Sub Styles – Client Server <ul><li>Separation of Concerns </li></ul><ul><li>Improve Portability of UI </li></ul><ul><li>Scalability per simple server components </li></ul><ul><li>Independent evolution </li></ul>Client Server
    6. 6. Sub Styles – CS+Stateless Com <ul><li>No context in server, session in client </li></ul><ul><li>All info needed is in message </li></ul><ul><li>Visibility, reliability, and scalability </li></ul><ul><li>Con: Decrease network performance </li></ul>Client Server Client Self Described Message with all info needed for operation
    7. 7. Sub Styles – CSS+Cache <ul><li>Interactions partially or completely eliminated </li></ul><ul><li>Reduced latency in average </li></ul><ul><li>Con: Decrease on reliability, cached data may not be the recently updated </li></ul>Client Server Client $ Cache will avoid full trip to server, and allow less server work
    8. 8. Sub Styles CSSC + Uniform Interface <ul><li>Principle of Generality on Interface </li></ul><ul><li>Simple Architecture, better visibility </li></ul><ul><li>Decoupling adds evolvability </li></ul><ul><li>Con: Degrades efficiency </li></ul><ul><li>Optimized: Large grain hypermedia transfer </li></ul>Client Server Client Same interface for all interactions, servers and nodes $
    9. 9. Sub Styles - Layered System <ul><li>Restrict knowledge of system to 1 layer </li></ul><ul><li>Bounds systems complexity + Encapsulation </li></ul><ul><li>Intermediaries and load balancing </li></ul><ul><li>Con: Add overhead and latency </li></ul><ul><li>Optim: Pipes & Filters behavior with intermediaries processing partially the message </li></ul>Client Interim Node Client Intermediary nodes can view the message and act upon it $ Server Other Interim Client
    10. 10. Sub Styles – Code On Demand <ul><li>Extend client functionality (extensibility) </li></ul><ul><li>Client simplification </li></ul><ul><li>Con: Reduces visibility </li></ul><ul><li>This is an optional constrain </li></ul>Client Interim Node Client Scripts can be downloaded to add features to clients $ Server Other Interim Client
    11. 11. Architectural Elements-Data <ul><li>How to render? Server, Client or mobile object </li></ul><ul><li>REST: Data types + Metadata + Interface hiding </li></ul><ul><li>Render in client… </li></ul><ul><li>… using partially generated representation in server… </li></ul><ul><li>… with instructions in metadata for independent engines </li></ul>
    12. 12. Architectural Elements-Data <ul><li>Resource is anything </li></ul><ul><li>Membership function M R (t) (t=time) </li></ul><ul><li>Maps Resource def to set of Representations and Ids </li></ul><ul><li>Static: Always returns the same set </li></ul><ul><li>Semantics should be the same for all sets of a resource </li></ul>
    13. 13. Architectural Elements-Data <ul><li>E.G. “My favorite song” set may vary over time </li></ul><ul><li>E.G. “The first song of Group X” is static. </li></ul><ul><li>This add generality without types </li></ul><ul><li>Allows late binding, requesting notion and not a representation instance </li></ul>
    14. 14. Architectural Elements-Data <ul><li>Resource Representation </li></ul><ul><li>Data, metadata, meta-metadata </li></ul><ul><li>Data format is a Media Type </li></ul><ul><li>Media Type definition is critical to user perceived performance and actual processing needs. </li></ul>
    15. 15. Universal Interface <ul><li>Identification of resources </li></ul><ul><li>Manipulation through representations </li></ul><ul><li>Self-descriptive messages </li></ul><ul><li>Hypermedia as the engine of application state . </li></ul>
    16. 16. Architectural Elements-Data <ul><li>Resource – The “it” </li></ul><ul><li>Resource Id - URI </li></ul><ul><li>Representation - HTML, JPEG, JSON </li></ul><ul><li>Rep. Metadata – Headers (media-type) </li></ul><ul><li>Res. Metadata – Source link, vary </li></ul><ul><li>Control data - if-modified-since, cache-control </li></ul>
    17. 17. Architec. Elements-Connectors <ul><li>Client – HTTP library </li></ul><ul><li>Server – Web Server API </li></ul><ul><li>Cache – Browser cache </li></ul><ul><li>Resolver - DNS </li></ul><ul><li>Tunnel - SSL </li></ul>
    18. 18. Architec. Elements-Components <ul><li>Origin Server – Apache, IIS </li></ul><ul><li>Gateway – CGI, Squid </li></ul><ul><li>Proxy – MS Proxy </li></ul><ul><li>User Agent - Browser </li></ul>
    19. 19. Word on Resource Ids <ul><li>URI, IRI, URN, URL </li></ul><ul><li>Use for identification, maybe location </li></ul><ul><li>URI is owned by server. </li></ul><ul><li>URI is provided by server dynamically - Discovered </li></ul><ul><li>Nice URIs tempt developer to violate discoverability </li></ul><ul><li>URI should not expose internals </li></ul>
    20. 20. HTTP - Operations <ul><li>GET </li></ul><ul><ul><li>Retrieve a representation </li></ul></ul><ul><ul><li>Retrieve a representation if modified (caching) </li></ul></ul><ul><li>DELETE </li></ul><ul><ul><li>Delete the resource </li></ul></ul>
    21. 21. HTTP - Operations <ul><li>PUT </li></ul><ul><ul><li>Create a resource with client-side managed instance id </li></ul></ul><ul><ul><li>Update a resource by replacing </li></ul></ul><ul><ul><li>Update a resource by replacing if not modified (optimistic locking) </li></ul></ul>
    22. 22. HTTP - Operations <ul><li>POST </li></ul><ul><ul><li>Create a resource with server-side managed (auto generated) instance id </li></ul></ul><ul><ul><li>Create a sub-resource </li></ul></ul><ul><ul><li>Partial update of a resource </li></ul></ul><ul><ul><li>Partial update a resource if not modified (optimistic locking) </li></ul></ul>
    23. 23. REST – Usual Example Obj. A Obj. B Obj. C Res. A Res. B Res. C H T T P
    24. 24. Usual Example <ul><li>Mapping </li></ul><ul><ul><li>Each object in the domain is one resource </li></ul></ul><ul><ul><li>There may be the need for additional resources </li></ul></ul><ul><ul><li>HTTP operations to manipulate know resources </li></ul></ul><ul><ul><li>Client to know what and how to post for processing. </li></ul></ul>
    25. 25. REST – Example Problems <ul><li>This approach exposes model domain </li></ul><ul><li>There is not encapsulation, nor data hiding </li></ul><ul><li>Resources are passive </li></ul><ul><li>Not using HATEOAS </li></ul>
    26. 26. REST – Alternative Example <ul><li>Use Services as resources </li></ul><ul><li>GET to bank/services resource returns an list of request forms for consuming services </li></ul><ul><li>Follow the links to forms, fill the forms and post. </li></ul><ul><li>Post the form to a bank/cashier resource </li></ul><ul><li>bank/cashier is a service! And a resource! </li></ul><ul><li>Post a Loan Request form and get a Loan Request ID </li></ul>
    27. 27. REST – Example Goodies <ul><li>This approach is business domain oriented </li></ul><ul><li>Encapsulates processing </li></ul><ul><li>Resources are active. </li></ul><ul><li>Follows HATEOAS constrain. </li></ul><ul><li>Not necessarily forms. Depends on app, can use ATOM and ATOMPub. </li></ul>
    28. 28. Questions?

    ×