Beyond REST An approach to creating stable, evolve-able Web - - PowerPoint PPT Presentation

beyond rest
SMART_READER_LITE
LIVE PREVIEW

Beyond REST An approach to creating stable, evolve-able Web - - PowerPoint PPT Presentation

Beyond REST An approach to creating stable, evolve-able Web applications Mike Amundsen @mamund Preamble Mike Amundsen Developer, Architect, Presenter Hypermedia Junkie I program the Internet. Designing Hypermedia APIs


slide-1
SLIDE 1

Beyond REST

An approach to creating stable, evolve-able Web applications

Mike Amundsen @mamund

slide-2
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
SLIDE 3

Preamble

  • Beyond REST
  • Not “Better than” REST
  • Not “After” REST
  • Just “Beyond” REST
slide-4
SLIDE 4

Overview

  • The Question
slide-5
SLIDE 5

Overview

  • The Question
  • A Few Observations
slide-6
SLIDE 6

Overview

  • The Question
  • A Few Observations
  • One Approach
slide-7
SLIDE 7

Overview

  • The Question
  • A Few Observations
  • One Approach
  • Some Techniques
slide-8
SLIDE 8

The Question

slide-9
SLIDE 9

The question is...

slide-10
SLIDE 10

The question is...

How can we design

slide-11
SLIDE 11

The question is...

How can we design and implement

slide-12
SLIDE 12

The question is...

How can we design and implement distributed network solutions that remain

slide-13
SLIDE 13

The question is...

How can we design and implement distributed network solutions that remain stable

slide-14
SLIDE 14

The question is...

How can we design and implement distributed network solutions that remain stable and flexible

slide-15
SLIDE 15

The question is...

How can we design and implement distributed network solutions that remain stable and flexible

  • ver time?
slide-16
SLIDE 16

The question is...

How can we design and implement distributed network solutions that remain stable and flexible

  • ver time?
slide-17
SLIDE 17

The question is...

How can we design and implement distributed network solutions that remain stable and flexible

  • ver time?

Evolvable systems.

slide-18
SLIDE 18

The question is...

How can we design and implement distributed network solutions that remain stable and flexible

  • ver time?

Evolvable systems.

slide-19
SLIDE 19

A Few Observations

slide-20
SLIDE 20

Definitions

slide-21
SLIDE 21

Definitions

  • Stability
slide-22
SLIDE 22

Definitions

  • Stability
  • "the strength to stand or endure" - Webster
slide-23
SLIDE 23

Stability

slide-24
SLIDE 24

Stability

slide-25
SLIDE 25

Definitions

  • Stability
  • "the strength to stand or endure" - Webster
slide-26
SLIDE 26

Definitions

  • Stability
  • "the strength to stand or endure" - Webster
  • Flexibility
slide-27
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
SLIDE 28

Flexibility

slide-29
SLIDE 29

Flexibility

slide-30
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
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

  • Time
slide-32
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
SLIDE 33

Time

slide-34
SLIDE 34

Time

slide-35
SLIDE 35

Time

slide-36
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
SLIDE 37

Another way to see it...

slide-38
SLIDE 38

Flexible

slide-39
SLIDE 39

Stable AND Flexible

slide-40
SLIDE 40

Stable AND Flexible Over Time

slide-41
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
SLIDE 42

One Approach

slide-43
SLIDE 43

A Model

slide-44
SLIDE 44

A Model

“Design depends largely on constraints” Charles Eames, 1972

slide-45
SLIDE 45

A Model

Protocol Semantics

slide-46
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
SLIDE 47

A Model

Protocol Semantics State Handling

slide-48
SLIDE 48

A Model

Protocol Semantics State Handling

slide-49
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
SLIDE 50

A Model

Protocol Semantics State Handling

slide-51
SLIDE 51

A Model

Protocol Semantics Domain Semantics State Handling

slide-52
SLIDE 52

A Model

Protocol Semantics Domain Semantics State Handling

slide-53
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
SLIDE 54

A Model

Protocol Semantics Domain Semantics State Handling

Connector Data Component

slide-55
SLIDE 55

Some Techniques

slide-56
SLIDE 56

Connector | Protocol Techniques

  • Embrace HTTP as the “network interface”
  • Methods
  • Response Codes
  • Headers
  • Media types
slide-57
SLIDE 57

This NOT an HTTP Interface

slide-58
SLIDE 58

HTTP Is NOT The Interface

slide-59
SLIDE 59

HTTP Is The Interface

slide-60
SLIDE 60

Connector | Protocol Techniques

  • Reduce HTTP Impedance Mismatch
  • Use frameworks that “talk” HTTP
  • Avoid libraries that hide HTTP
slide-61
SLIDE 61

Reduce HTTP Impedance Mismatch

slide-62
SLIDE 62

Component | State Techniques

  • Honor State Boundaries
  • Publicly state-less
  • privately state-ful
slide-63
SLIDE 63

State Boundaries

slide-64
SLIDE 64

Component | State Techniques

  • Avoid Session Tracking
  • All you need to share is “who”
slide-65
SLIDE 65

All you need to share is “who”

slide-66
SLIDE 66

Component | State Techniques

  • Avoid State “Design” Leaking
  • State belongs to components, not connectors
slide-67
SLIDE 67

Avoid Leaking State Design

slide-68
SLIDE 68

Data | Domain Techniques

  • Avoid Type Marshalling|Object Serialization
slide-69
SLIDE 69

Data | Domain Techniques

  • Avoid Type Marshalling|Object Serialization
  • Use Templating Instead
slide-70
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
SLIDE 71

Data | Domain Techniques

  • Maximize Hypermedia
  • State Transfer
  • Domain Style
  • App Flow
slide-72
SLIDE 72

Data | Domain Techniques

  • Model w/ Media Types
  • Document Media Type, not interactions
  • Replace RPC designs w/ Media Type designs
slide-73
SLIDE 73

Model with Media Types

slide-74
SLIDE 74

Summary

slide-75
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
SLIDE 76

Design … Discipline

“Design without discipline is anarchy, an exercise of irresponsibility” Massimo Vignelli, 2010

slide-77
SLIDE 77

Beyond REST

An approach to creating stable, evolve-able Web applications

Mike Amundsen @mamund