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