Beyond REST: An approach to creating stable, evolve-able Web applications (2011-05-13)

697 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
697
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Beyond REST: An approach to creating stable, evolve-able Web applications (2011-05-13)

  1. 1. Beyond RESTAn approach to creating stable, evolve-able Web applications Mike Amundsen @mamund
  2. 2. Preamble• Mike Amundsen• Developer, Architect, Presenter• Hypermedia Junkie• “I program the Internet.”• Designing Hypermedia APIs with Node and HTML5 Fall 2011
  3. 3. Preamble• Beyond REST• Not “Better than” REST• Not “After” REST• Just “Beyond” REST
  4. 4. Overview• The Question
  5. 5. Overview• The Question• A Few Observations
  6. 6. Overview• The Question• A Few Observations• One Approach
  7. 7. Overview• The Question• A Few Observations• One Approach• Some Techniques
  8. 8. The Question
  9. 9. The question is...
  10. 10. The question is...How can we design
  11. 11. The question is...How can we designand implement
  12. 12. The question is...How can we designand implementdistributed network solutionsthat remain
  13. 13. The question is...How can we designand implementdistributed network solutionsthat remainstable
  14. 14. The question is...How can we designand implementdistributed network solutionsthat remainstableandflexible
  15. 15. The question is...How can we designand implementdistributed network solutionsthat remainstableandflexibleover time?
  16. 16. The question is...How can we designand implementdistributed network solutionsthat remainstableandflexibleover time?
  17. 17. The question is...How can we designand implementdistributed network solutionsthat remainstableandflexibleover time?Evolvable systems.
  18. 18. The question is...How can we designand implementdistributed network solutionsthat remainstableandflexibleover time?Evolvable systems.
  19. 19. A Few Observations
  20. 20. Definitions
  21. 21. Definitions• Stability
  22. 22. Definitions• Stability o "the strength to stand or endure" - Webster
  23. 23. Stability
  24. 24. Stability
  25. 25. Definitions• Stability o "the strength to stand or endure" - Webster
  26. 26. Definitions• Stability o "the strength to stand or endure" - Webster• Flexibility
  27. 27. Definitions• Stability o "the strength to stand or endure" - Webster• Flexibility o "characterized by a ready capability to adapt to new, different, or changing requirements." - Webster
  28. 28. Flexibility
  29. 29. Flexibility
  30. 30. Definitions• Stability o "the strength to stand or endure" - Webster• Flexibility o "characterized by a ready capability to adapt to new, different, or changing requirements." - Webster
  31. 31. Definitions• Stability o "the strength to stand or endure" - Webster• Flexibility o "characterized by a ready capability to adapt to new, different, or changing requirements." - Webster• Time
  32. 32. Definitions• Stability o "the strength to stand or endure" - Webster• Flexibility o "characterized by a ready capability to adapt to new, different, or changing requirements." - Webster• Time o "a nonspatial continuum that is measured in terms of events which succeed one another from past through present to future." - Webster
  33. 33. Time
  34. 34. Time
  35. 35. Time
  36. 36. On the scale of years“Most of RESTs constraints are focused onpreserving independent evolvability over time, whichis only measurable on the scale of years. Roy Fielding, August 2010
  37. 37. Another way to see it...
  38. 38. Flexible
  39. 39. Stable AND Flexible
  40. 40. Stable AND Flexible Over Time
  41. 41. Alive … Stable“In short, saying these [patterns] are alive is more or less thesame as saying they are stable.” Christopher Alexander, 1979
  42. 42. One Approach
  43. 43. A Model
  44. 44. A Model“Design depends largely on constraints” Charles Eames, 1972
  45. 45. A Model Protocol Semantics
  46. 46. A Model • The transfer protocol • HTTP, FTP, etc. • Standardized (RFCs, etc.) • Slowest changing • Shared by all participants Protocol Semantics • Use “as-is” • The stable foundation
  47. 47. A Model Protocol State Semantics Handling
  48. 48. A Model Protocol State Semantics Handling
  49. 49. A Model • Identification • Sharing • Storage • Transient • Unique for each participant State Handling • Create/Manipulate as Needed • Identify & share via message • Media type • Headers • Store locally
  50. 50. A Model Protocol State Semantics Handling
  51. 51. A Model Protocol Domain State Semantics Semantics Handling
  52. 52. A Model Protocol Domain State Semantics Semantics Handling
  53. 53. A Model • Application-level semantics • Discover • Encapsulate • Describe • Shared Understanding Domain • For acknowledged participants Semantics • Evolvable over time • Message-Enabled • Media type • Semantic Profile, etc
  54. 54. A Model Connector Data Component Protocol Domain State Semantics Semantics Handling
  55. 55. Some Techniques
  56. 56. Connector | Protocol Techniques• Embrace HTTP as the “network interface” • Methods • Response Codes • Headers • Media types
  57. 57. This NOT an HTTP Interface
  58. 58. HTTP Is NOT The Interface
  59. 59. HTTP Is The Interface
  60. 60. Connector | Protocol Techniques• Reduce HTTP Impedance Mismatch• Use frameworks that “talk” HTTP• Avoid libraries that hide HTTP
  61. 61. Reduce HTTP Impedance Mismatch
  62. 62. Component | State Techniques• Honor State Boundaries• Publicly state-less• privately state-ful
  63. 63. State Boundaries
  64. 64. Component | State Techniques• Avoid Session Tracking• All you need to share is “who”
  65. 65. All you need to share is “who”
  66. 66. Component | State Techniques• Avoid State “Design” Leaking• State belongs to components, not connectors
  67. 67. Avoid Leaking State Design
  68. 68. Data | Domain Techniques• Avoid Type Marshalling|Object Serialization
  69. 69. Data | Domain Techniques• Avoid Type Marshalling|Object Serialization • Use Templating Instead
  70. 70. Data | Domain Techniques• Use MVC Wisely• “Fat” M (not just DB serialization)• “Loose” V (templates, not codecs)• “Decoupled” C (SoC for addressing)
  71. 71. Data | Domain Techniques• Maximize Hypermedia • State Transfer • Domain Style • App Flow
  72. 72. Data | Domain Techniques• Model w/ Media Types • Document Media Type, not interactions • Replace RPC designs w/ Media Type designs
  73. 73. Model with Media Types
  74. 74. Summary
  75. 75. Summary• How can we make implementations more flexible and stable over time?• Make time your ally• Design “living” systems• Embrace Connector+Component+Data Model• Adopt techniques that • Embrace the protocol • Play to strengths in each design element (CCD) • Recognize clear boundaries
  76. 76. Design … Discipline“Design without discipline is anarchy, an exercise ofirresponsibility” Massimo Vignelli, 2010
  77. 77. Beyond RESTAn approach to creating stable, evolve-able Web applications Mike Amundsen @mamund

×