Who am I?
CTO at Redbooth
@masylum at Github and Twitter
Tuesday, May 27, 14
Slide 3
Slide 3 text
HTTP
The stateless protocol
Tuesday, May 27, 14
Slide 4
Slide 4 text
Getting snapshots
of the current state
is simple but
inefficient.
Tuesday, May 27, 14
Slide 5
Slide 5 text
Realtime?
Tuesday, May 27, 14
Slide 6
Slide 6 text
There must be a better way
Tuesday, May 27, 14
Slide 7
Slide 7 text
AJAX
the raise of the stateful
web clients
Tuesday, May 27, 14
Slide 8
Slide 8 text
The web becomes
realtime.
Tuesday, May 27, 14
Slide 9
Slide 9 text
Keeping state in
your client is
efficient but
complex.
Tuesday, May 27, 14
Slide 10
Slide 10 text
The client state
diverges from the
app state over time.
Tuesday, May 27, 14
Slide 11
Slide 11 text
Eventual consistency
is hard.
Tuesday, May 27, 14
Slide 12
Slide 12 text
GET /users/1
Client Server
Client Server
Tuesday, May 27, 14
Slide 13
Slide 13 text
State and
presentation
shouldn’t be
coupled.
Tuesday, May 27, 14
Slide 14
Slide 14 text
Much coupling
Tuesday, May 27, 14
Slide 15
Slide 15 text
APIs
Exposing your state to the
world!
Tuesday, May 27, 14
Slide 16
Slide 16 text
Any client can
access to the state
and interact with it.
Tuesday, May 27, 14
Slide 17
Slide 17 text
Clients are
responsible for the
presentation layer.
Tuesday, May 27, 14
Slide 18
Slide 18 text
Clients and API’s
are difficult to
maintain.
Tuesday, May 27, 14
Slide 19
Slide 19 text
No conventions
=
Boilerplate
Tuesday, May 27, 14
Slide 20
Slide 20 text
Too much work!
Tuesday, May 27, 14
Slide 21
Slide 21 text
REST APIs
Convention over
configuration
Tuesday, May 27, 14
Slide 22
Slide 22 text
Resource
List of
resources
List of resources
Client
Server
Robert (3)
/cats
/dogs
grumpy.gif
lolcat.png
Tuesday, May 27, 14
Slide 23
Slide 23 text
GET /users
GET /users/1
POST /users
PUT /users/1
Fetch list of resources
Fetch a resource
Create a resource
Update a resource
Destroy a resource
DELETE /users/1
REST in a nutshell
Tuesday, May 27, 14
Slide 24
Slide 24 text
Conventions
increase
predictability.
Tuesday, May 27, 14
Slide 25
Slide 25 text
Having a unified
“language” for
server and clients
increase teams
productivity
Tuesday, May 27, 14
Slide 26
Slide 26 text
I’m so productive
Tuesday, May 27, 14
Slide 27
Slide 27 text
REST client
Patterns
Tuesday, May 27, 14
Slide 28
Slide 28 text
Side effects
(›°□°ʣ›ớ ᵲᴸᵲ
Tuesday, May 27, 14
Slide 29
Slide 29 text
Example:
POST /pictures Creates a picture
Increases user “karma”
GET /users/1 Gets user resource with
the new “karma” score
Side effect!
(›°□°ʣ›ớ ᵲᴸᵲ
Tuesday, May 27, 14
Slide 30
Slide 30 text
The side effect can
be avoided if its
originated from the
client.
Tuesday, May 27, 14
Slide 31
Slide 31 text
Otherwise the
client can fetch the
resource to achieve
consistency.
Tuesday, May 27, 14
Slide 32
Slide 32 text
Beware of side effects
Tuesday, May 27, 14
Slide 33
Slide 33 text
Patch
Minimize race conditions
on updating resources
Tuesday, May 27, 14
Slide 34
Slide 34 text
Example:
{...name:‘Bob’, karma:3}
Client A
Robert (3) PUT /users/1
Client B
{...name:‘Robert’, karma:4}
PUT /users/1
Robert (3)
Tuesday, May 27, 14
Slide 35
Slide 35 text
Multiple clients can
mutate the state at
the same time.
Tuesday, May 27, 14
Slide 36
Slide 36 text
Minimize race
conditions with
PATCH instead of
PUT.
Tuesday, May 27, 14
Slide 37
Slide 37 text
Example:
{name:‘Bob’}
Client A
Robert (3) PATCH /users/1
Client B
{karma:4}
PATCH /users/1
Robert (3)
Tuesday, May 27, 14
Slide 38
Slide 38 text
Avoid race
conditions
Tuesday, May 27, 14
Slide 39
Slide 39 text
Relations
They are difficult
Tuesday, May 27, 14
Slide 40
Slide 40 text
Example:
A folder has many pictures
/cats
/dogs
grumpy.gif
lolcat.png
Tuesday, May 27, 14
A list of folder resources
[
{id: 1..., pictures: [...]}
, {id: 2..., pictures: [...]}
]
Tuesday, May 27, 14
Slide 43
Slide 43 text
• You bring more state at once
• Increased perceived performance
• Less requests to the server
Pros
Tuesday, May 27, 14
Slide 44
Slide 44 text
• Worse “cacheability”
• Inefficient, you may not need all
that state
• Too much state transfer: Side
effects everywhere!
Cons
Tuesday, May 27, 14
Slide 45
Slide 45 text
Bet on “flat” APIs.
They are more
performant and
easy to maintain
Tuesday, May 27, 14
Slide 46
Slide 46 text
Love flat
APIs
Tuesday, May 27, 14
Slide 47
Slide 47 text
Optimism
If an API is slow, pretend
it’s not
Tuesday, May 27, 14
Slide 48
Slide 48 text
Example:
{name:‘Bob’}
Bob
Client Server
Robert
{id:1,name:‘Bob’}
Bob
Bob
Robert Robert
PATCH /users/1
Response
Tuesday, May 27, 14
Slide 49
Slide 49 text
• Increased perceived performance
• Clients can approximate a slow API
operation
• Narrows down the “eventual
consistency” gap
Pros
Tuesday, May 27, 14
Slide 50
Slide 50 text
• Error handling may be difficult
• Reverting to previous state can be
weird
• Duplicated code in the server and
the clients
Cons
Tuesday, May 27, 14
Slide 51
Slide 51 text
Be optimistic when
the worse case
scenario is not
critical.
Tuesday, May 27, 14
Slide 52
Slide 52 text
Having the same
language in both
the client and the
server can help.
Tuesday, May 27, 14
Slide 53
Slide 53 text
Embrace optimism
Tuesday, May 27, 14
Slide 54
Slide 54 text
Async operations
Deal with really long API
requests
Tuesday, May 27, 14
Slide 55
Slide 55 text
Example:
Client Server
DELETE /users/1
408 Request Timeout
120 seconds later
Tuesday, May 27, 14
Slide 56
Slide 56 text
The API returns a
token that you can
poll to determine
the status of the
operation
Tuesday, May 27, 14
Slide 57
Slide 57 text
Example:
Client Server
DELETE /users/1
GET /token/c13Dr9
{status: ‘success’}
{token: ‘c13Dr9’}
120 seconds later
Tuesday, May 27, 14
Slide 58
Slide 58 text
Do not timeout!
Tuesday, May 27, 14
Slide 59
Slide 59 text
Data syncing
Bring only the state that
you need
Tuesday, May 27, 14
Slide 60
Slide 60 text
Keep long
lived-resources
Stateful
Tuesday, May 27, 14
Slide 61
Slide 61 text
Keep short-lived
resources
Stateless
Tuesday, May 27, 14
Slide 62
Slide 62 text
Long-lived
resources can be
stored on the client
and then only sync
differences
Tuesday, May 27, 14
Slide 63
Slide 63 text
Example:
Client Server
GET /users
GET /users?since=1401145798
{add: [{...}]}
[120x{...}]
2 days later
Tuesday, May 27, 14
Slide 64
Slide 64 text
Re-Learn HTTP
Tuesday, May 27, 14
Slide 65
Slide 65 text
Final thoughts
Tuesday, May 27, 14
Slide 66
Slide 66 text
Embrace HTTP as
much as possible.
Stateful clients are
really hard!
Tuesday, May 27, 14
Slide 67
Slide 67 text
REST still requires
too much
boilerplate for
server and clients
Tuesday, May 27, 14
Slide 68
Slide 68 text
API’s are like
databases.
We need a better
way to interact
with them
Tuesday, May 27, 14