The Why Of REST

913 views

Published on

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
913
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Why Of REST

  1. 1. The Why ofREST<br />William Martínez Pomares<br />Architect and R&D Manager<br />Avantica Technologieswmartinez@avantica.net<br />
  2. 2. Who Am I and Why I’m Here?<br />
  3. 3. Agenda<br />REST What?<br />Application Types<br />The Constrain Trade-off<br />SOA Match Up<br />Suitability<br />
  4. 4. NO, REST is not…<br />RPC<br />API<br />URI<br />W.S.<br />PROTOCOL!<br />“An RPC protocol running over SOAP …”<br />Charlie Kaufman and RamanathanVenkatapathy - Windows Azure™ Security Overview<br />
  5. 5. YES, REST is….<br />“…architectural style for distributed hypermedia systems …”<br />Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 5<br />“to minimize latency and network communication, while at the same time maximizing the independence and scalability of component implementations”<br />Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 5<br />
  6. 6. Styling Styles<br />Style Definition<br />Name<br />Context<br />Forces<br />Problem<br />Solution<br />Consequences<br />Style REST’s style<br />“An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.”<br />Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, 1.5<br />Play Analogy<br />
  7. 7. Application Types<br />
  8. 8. Distributed Application<br /><ul><li>Application as a Whole
  9. 9. Tight connections
  10. 10. High speed communication
  11. 11. Strong coupling
  12. 12. Reuse of Parts Optional</li></li></ul><li>Networked Application<br /><ul><li>Application as a Composition of Nodes
  13. 13. Weak coupling
  14. 14. High cost communication
  15. 15. User aware of composition
  16. 16. Reuse of Parts is common</li></li></ul><li>Integrated Application<br /><ul><li>Application as an Integration of Whole Applications
  17. 17. Standard Interfaces
  18. 18. Low frequency of interaction
  19. 19. Higher level processes
  20. 20. Reuse of Parts is rule
  21. 21. Large distribution</li></li></ul><li>The …ilities<br />
  22. 22. The …ilities<br />
  23. 23. Client Server <br /><ul><li>Separation of Concerns
  24. 24. Improve Portability of UI
  25. 25. Scalability per simple server components
  26. 26. Independent evolution</li></ul>Server<br />Client<br />
  27. 27. Client Server<br /><ul><li>Indirect cost of communication
  28. 28. Concept degraded to hardware view
  29. 29. Interaction Model may confuse Messaging with RPC</li></ul>Server<br />Client<br />
  30. 30. CS + Stateless Communication<br /><ul><li>No context in server, session in client
  31. 31. All info needed is in message
  32. 32. Visibility: For Monitoring
  33. 33. Reliability: Partial recovery
  34. 34. Scalability: No server stored session</li></ul>Server<br />Client<br />
  35. 35. CS + Stateless Communication<br /><ul><li>Decrease of performance due to increase on communication payload
  36. 36. Takes away application control from server and places it into clients.</li></ul>Server<br />Client<br />
  37. 37. CSSC + Cache<br /><ul><li>Improves performance by decreasing interactions
  38. 38. Reduces average latency.
  39. 39. Reduces processing on server by reusing results of processed data.
  40. 40. Can be multilevel </li></ul>Server<br />Client<br />
  41. 41. CSSC + Cache<br /><ul><li>Decrease of Reliability: Cached data may not be recently updated
  42. 42. Implementation and storage cost
  43. 43. Requires client awareness</li></ul>Server<br />Client<br />
  44. 44. CSSCC + Uniform Interface<br /><ul><li>Principle of Generality on Interface
  45. 45. Simple Architecture, better visibility
  46. 46. Decoupling.
  47. 47. Adds Independent Evolvability.</li></ul>Server<br />Client<br />Server<br />
  48. 48. CSSCC + Uniform Interface<br /><ul><li>Degrades Efficiency
  49. 49. Impedance Mismatch since information is transferred in uniform format rather than most suitable.
  50. 50. May add processing cost due to transformation
  51. 51. Reduces visibility on Interface</li></ul>Server<br />Client<br />Server<br />
  52. 52. Uniform Interface: REST Case<br />Optimized for Large Grain Hypermedia Transfer<br />Identifiable Resource concept<br />Manipulation of resources by representations<br />Self-descriptive messages <br />Hypermedia as the engine of application state<br />
  53. 53. The SOA Case<br />Large Distributed Systems<br />Legacy<br />Heterogeneous<br />Complex<br />Imperfect<br />Redundant<br />Business service, process oriented<br />Nicolai M. Josuttis,SOA in Practice, OREILLY<br />
  54. 54. SOA – Process Oriented<br />Messaging: Send data to a service for processing. RPC?<br />No operation in protocol<br />Business as a process, not as data<br />Processes as resources<br />Discoverable by repository, centralized<br />No flow control. External or out of band<br />Business semantics<br />
  55. 55. REST – Hypermedia Oriented<br />Messaging: Send/Receive representation. No RPC.<br />Finite Operation set in protocol<br />Not about business<br />Datum as resources<br />Discoverable by link, distributed<br />Hypermedia as the State Engine<br />Mixed semantics<br />
  56. 56. SOA – REST Match Up<br />Different types of applications<br />REST as Special Service construction architecture<br />Large distributed data<br />Hypermedia related or Insensible to format transformation.<br />Relaxed Security <br />Independent evolution requirement<br />Non processing intensive<br />Non sensitive to performance hits, cacheable.<br />
  57. 57. Questions?<br />

×