Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Building better clients
Search
Ben Longden
September 11, 2014
Technology
0
50
Building better clients
Ben Longden
September 11, 2014
Tweet
Share
More Decks by Ben Longden
See All by Ben Longden
Spryker, an architecture for the web
blongden
0
260
Adaptive and evolvable apps
blongden
0
400
Silex, the micro-framework
blongden
3
550
Other Decks in Technology
See All in Technology
Symfony in 2025: Scaling to 0
fabpot
2
270
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
240
Restarting_SRE_Road_to_SRENext_.pdf
_awache
1
220
20250328_OpenAI製DeepResearchは既に一種のAGIだと思う話
doradora09
PRO
0
180
Startups On Rails 2025 @ Tropical on Rails
irinanazarova
0
180
Zabbixチョットデキルとは!?
kujiraitakahiro
0
120
大規模サービスにおける カスケード障害
takumiogawa
3
770
やさしいMCP入門
minorun365
PRO
134
77k
こんなデータマートは嫌だ。どんな? / waiwai-data-meetup-202504
shuntak
2
560
大規模プロジェクトにおける 品質管理の要点と実践 / 20250327 Suguru Ishii
shift_evolve
0
320
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
130
開発現場とセキュリティ担当をつなぐ脅威モデリング
cloudace
0
130
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
118
51k
How to Ace a Technical Interview
jacobian
276
23k
Code Review Best Practice
trishagee
67
18k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
Become a Pro
speakerdeck
PRO
27
5.2k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
Documentation Writing (for coders)
carmenintech
69
4.7k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
GitHub's CSS Performance
jonrohan
1030
460k
Designing for humans not robots
tammielis
251
25k
Fireside Chat
paigeccino
37
3.4k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
102
19k
Transcript
BUILDING BETTER CLIENTS
BEN LONGDEN CTO Inviqa Enterprise open source
@BLONGDEN
There are two types of client
MACHINE DRIVEN
HUMAN DRIVEN
WHAT'S THE PROBLEM?
We're getting quite good better at building RESTful API's on
the server side.
But what about our clients?
Do they allow the API to change?
Consider the web browser.
What would the browser do? — Brian Sletten
Supports the most common media types.
application/x-shockwave-flash
Versioning
HTML
We're not building a web browser
But we can be inspired
CONTENT NEGOTIATION (CONNEG)
Send what your client will accept
Accept: application/hal+json, text/plain
Check what the server sends back
Content-Type: application/hal+json
Allow clients to support new media types when they become
available
Accept: application/hal+json, application/ vnd.error+json, text/plain;q=0.9
USE AN HTTP CLIENT
CACHEING
URLS
Remember that any GET request can be bookmarked by a
client
But also that it could result in a redirect
GUZZLE ▸ Cacheing ▸ Logging ▸ Oauth
HYPERMEDIA CONSTRAINT
Hypermedia is defined by the presence of application control information
embedded within, or as a layer above, the presentation of information — Roy Fielding
LINK RELATIONS POSSIBLE STATES
CONTEXT
{ "_links": { "self": { "href": "/comment/3864362" } }, "content":
"lol" }
{ "_links": { "edit": { "href": "/comment/3864362" }, "self": {
"href": "/comment/3864362" } }, "content": "lol" }
None
CLIENT CAN EVOLVE INDEPENDENTLY
None
Futureproof?
DESIGN OF EVERYDAY THINGS
Form a goal
Intention to act
Sequence of actions
Execution of the sequence of action
Perceive the state of the world
Interpret the perception
Evaluate the outcome
None
Why am I talking about this?
A hypermedia client works in much the same way
Let the server be in control
Use content negotiation to allow clients to evolve
Use an HTTP client and turn on cacheing
Drive human interaction through hypermedia controls
None
QUESTIONS! (or ask me at the bar later)