REST clients

REST clients Tuesday, May 27, 14

Who am I? CTO at Redbooth @masylum at Github and
Twitter Tuesday, May 27, 14

HTTP The stateless protocol Tuesday, May 27, 14

Getting snapshots of the current state is simple but inefﬁcient.
Tuesday, May 27, 14

Realtime? Tuesday, May 27, 14

There must be a better way Tuesday, May 27, 14

AJAX the raise of the stateful web clients Tuesday, May
27, 14

The web becomes realtime. Tuesday, May 27, 14

Keeping state in your client is efﬁcient but complex. Tuesday,
May 27, 14

The client state diverges from the app state over time.
Tuesday, May 27, 14

Eventual consistency is hard. Tuesday, May 27, 14

GET /users/1 Client Server <html> Client Server Tuesday, May 27,
14

State and presentation shouldn’t be coupled. Tuesday, May 27, 14

Much coupling Tuesday, May 27, 14

APIs Exposing your state to the world! Tuesday, May 27,
14

Any client can access to the state and interact with
it. Tuesday, May 27, 14

Clients are responsible for the presentation layer. Tuesday, May 27,
14

Clients and API’s are difﬁcult to maintain. Tuesday, May 27,
14

No conventions = Boilerplate Tuesday, May 27, 14

Too much work! Tuesday, May 27, 14

REST APIs Convention over conﬁguration Tuesday, May 27, 14

Resource List of resources List of resources Client Server Robert
(3) /cats /dogs grumpy.gif lolcat.png Tuesday, May 27, 14

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

Conventions increase predictability. Tuesday, May 27, 14

Having a uniﬁed “language” for server and clients increase teams
productivity Tuesday, May 27, 14

I’m so productive Tuesday, May 27, 14

REST client Patterns Tuesday, May 27, 14

Side effects (›°□°ʣ›ớ ᵲᴸᵲ Tuesday, May 27, 14

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

The side effect can be avoided if its originated from
the client. Tuesday, May 27, 14

Otherwise the client can fetch the resource to achieve consistency.
Tuesday, May 27, 14

Beware of side effects Tuesday, May 27, 14

Patch Minimize race conditions on updating resources Tuesday, May 27,
14

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

Multiple clients can mutate the state at the same time.
Tuesday, May 27, 14

Minimize race conditions with PATCH instead of PUT. Tuesday, May
27, 14

Example: {name:‘Bob’} Client A Robert (3) PATCH /users/1 Client B
{karma:4} PATCH /users/1 Robert (3) Tuesday, May 27, 14

Avoid race conditions Tuesday, May 27, 14

Relations They are difﬁcult Tuesday, May 27, 14

Example: A folder has many pictures /cats /dogs grumpy.gif lolcat.png
Tuesday, May 27, 14

A folder resource { id: 1 , name: ‘cats’ ,
pictures: [ {id: 1, name: ‘1.gif} ]} Tuesday, May 27, 14

A list of folder resources [ {id: 1..., pictures: [...]}
, {id: 2..., pictures: [...]} ] Tuesday, May 27, 14

• You bring more state at once • Increased perceived
performance • Less requests to the server Pros Tuesday, May 27, 14

• Worse “cacheability” • Inefﬁcient, you may not need all
that state • Too much state transfer: Side effects everywhere! Cons Tuesday, May 27, 14

Bet on “ﬂat” APIs. They are more performant and easy
to maintain Tuesday, May 27, 14

Love ﬂat APIs Tuesday, May 27, 14

Optimism If an API is slow, pretend it’s not Tuesday,
May 27, 14

Example: {name:‘Bob’} Bob Client Server Robert {id:1,name:‘Bob’} Bob Bob Robert
Robert PATCH /users/1 Response Tuesday, May 27, 14

• Increased perceived performance • Clients can approximate a slow
API operation • Narrows down the “eventual consistency” gap Pros Tuesday, May 27, 14

• Error handling may be difﬁcult • Reverting to previous
state can be weird • Duplicated code in the server and the clients Cons Tuesday, May 27, 14

Be optimistic when the worse case scenario is not critical.
Tuesday, May 27, 14

Having the same language in both the client and the
server can help. Tuesday, May 27, 14

Embrace optimism Tuesday, May 27, 14

Async operations Deal with really long API requests Tuesday, May
27, 14

Example: Client Server DELETE /users/1 408 Request Timeout 120 seconds
later Tuesday, May 27, 14

The API returns a token that you can poll to
determine the status of the operation Tuesday, May 27, 14

Example: Client Server DELETE /users/1 GET /token/c13Dr9 {status: ‘success’} {token:
‘c13Dr9’} 120 seconds later Tuesday, May 27, 14

Do not timeout! Tuesday, May 27, 14

Data syncing Bring only the state that you need Tuesday,
May 27, 14

Keep long lived-resources Stateful Tuesday, May 27, 14

Keep short-lived resources Stateless Tuesday, May 27, 14

Long-lived resources can be stored on the client and then
only sync differences Tuesday, May 27, 14

Example: Client Server GET /users GET /users?since=1401145798 {add: [{...}]} [120x{...}]
2 days later Tuesday, May 27, 14

Re-Learn HTTP Tuesday, May 27, 14

Final thoughts Tuesday, May 27, 14

Embrace HTTP as much as possible. Stateful clients are really
hard! Tuesday, May 27, 14

REST still requires too much boilerplate for server and clients
Tuesday, May 27, 14

API’s are like databases. We need a better way to
interact with them Tuesday, May 27, 14

Questions? Tuesday, May 27, 14

REST clients

REST clients

More Decks by masylum

Other Decks in Programming

Featured

Transcript