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
REST - Valtech
Search
Mårten Gustafson
March 09, 2012
Programming
4
390
REST - Valtech
Presentation on REST given at Valtech Stockholm.
Approx 60 minutes.
Mårten Gustafson
March 09, 2012
Tweet
Share
More Decks by Mårten Gustafson
See All by Mårten Gustafson
Github all the things!
chids
3
350
Bastardised Kanban
chids
0
1.5k
Heroku as a production platform
chids
0
180
DevOps @ KnowIT
chids
0
170
Opinions on DevOps
chids
2
620
The OPS side of DEV
chids
9
4.6k
[Swedish] NoSQL at Javaforum Stockholm
chids
2
160
Approaching and evaluating NoSQL
chids
3
170
Automation @ Hitta.se and why it happened
chids
1
270
Other Decks in Programming
See All in Programming
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
7
980
202507_ADKで始めるエージェント開発の基本 〜デモを通じて紹介〜(奥田りさ)
risatube
PRO
5
1.2k
MySQL9でベクトルカラム登場!PHP×AWSでのAI/類似検索はこう変わる
suguruooki
1
240
AI コーディングエージェントの時代へ:JetBrains が描く開発の未来
masaruhr
2
220
副作用と戦う PHP リファクタリング ─ ドメインイベントでビジネスロジックを解きほぐす
kajitack
3
460
「次に何を学べばいいか分からない」あなたへ──若手エンジニアのための学習地図
panda_program
3
650
AI Ramen Fight
yusukebe
0
110
リッチエディターを安全に開発・運用するために
unachang113
1
250
Streamlitで実現できるようになったこと、実現してくれたこと
ayumu_yamaguchi
2
220
知って得する@cloudflare_vite-pluginのあれこれ
chimame
1
120
Reactの歴史を振り返る
tutinoko
1
140
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
Featured
See All Featured
How to Think Like a Performance Engineer
csswizardry
25
1.8k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Producing Creativity
orderedlist
PRO
346
40k
Practical Orchestrator
shlominoach
189
11k
Art, The Web, and Tiny UX
lynnandtonic
301
21k
A designer walks into a library…
pauljervisheath
207
24k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Agile that works and the tools we love
rasmusluckow
329
21k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Transcript
Hi! My name is Mårten Gustafson
I used to work here...
...now I work here... (and I brought give-away readers)
Representational State Transfer
Representational State Transfer
REST
RESTful
HTTP
means of INTEGRATING disparate stuff
(my DARK and shameful PAST) * 4 years of: **
IBM WebSphere ** ESB ** SOAP/WSDL ** Enterprisey * REST vs SOAP vs HTTP vs JMS vs WMQ vs PUB/SUB vs EDA vs HA vs D/R
INTEGRATIONs
APIs
INTERFACEs
UNIFORM * REST defines a uniform interface * As opposed
to SOAP, CORBA, etc
GET PUT POST DELETE - list all foo - 501
- create a new foo - 501 a/b/c/foo
GET PUT POST DELETE - details of {id} - update
the {id} - 501 - delete the {id} a/b/c/foo/{id}
VERBs
(OPTIONS) * not common (yet) * mention: pre-flight
GET * retrieve
HEAD * retrieve without content (ie metadata)
POST * create (without known id) or update (with/without -
unsafe)
PUT * update or create with known id (idempotent)
DELETE * remove
(TRACE) * ?
(CONNECT) * ?
IDEMPOTENT * Without side effects * Fine to call multiple
times
safe idempotent unsafe OPTIONS X (x) GET X (x) HEAD
X (x) POST X PUT X X DELETE X X TRACE X (x) CONNECT
DEVELOPing
WELL BEHAVED * be well behaved * read up on
HTTP/1.1
ETag * The most overlooked HTTP header in API design?
Allows concurrency control * if-match: “<etag>” * if-none-match: “<etag>” * 304 not modified * version number
VARY * Tell clients/caches which headers that forms the response
(ie what’s the cache-combo) * ie: Vary: Accept ( /foo/bar vs /foo/bar : XML vs JSON)
CACHE-CONTROL * age * no-cache * no-store
EXPIRES * Expire any cached copies after...
BENEFITs
CLIENTS PROXIES SERVERS LOAD BALANCERS * will all understand and
act accordingly * in addition cool modern software does HTTP/REST out-of-the-box (CouchDB, Riak)
PLANNING
URLs * What will your URL scheme look like *
How will it evolve * Identify natural points of extension/evolution
DNS * This is part of your URL * Think
about partitioning (subdomains) * Think about future transition, separation, isolation * Does Wildcard DNS make sense to you?
SECURITY * HTTPS + basic auth (one stop shop) *
API auth (client certificates, OAuth) * SSL cookies
VERSIONING * This is the hard part
http://api.foo/v1/bar application/xml + easy (ie browser compatible)
http://api.foo/v1/bar application/xml - URL changes with version - Breaks the
URL = resource REST thingy
http://api.foo/bar application/vnd.bar-v1+xml - hard (ie NOT browser compatible)
http://api.foo/bar application/vnd.bar-v1+xml + version is independent of URL
application/vnd.foo-v1+xml application/vnd.foo-v2+xml * Vary: “Accept”
REPRESENTATION
http://api.foo/bar application/xml + easy (ie browser compatible)
http://api.foo/bar.xml + even easier (ie really browser compatible) - more
info in URL
http://api.foo/bar application/vnd.bar-v1+xml
http://api.foo/bar application/vnd.bar-v1+xml + representation is independent of URL
USABILITY
PROXIES
http://api.foo/v1/bar.xml
http://api.foo/v1/bar.xml
http://api.foo/v1/bar.xml http://api.foo/bar
http://api.foo/v1/bar.xml http://api.foo/bar application/vnd.bar-v1+xml
http://api.foo/v1/bar.xml http://api.foo/bar application/vnd.bar-v1+xml
http://api.foo/v1/bar.xml http://api.foo/bar application/vnd.bar-v1+xml
HATEOAS
WAT?!
LINKs * State transitions
MIMEs * Representations
LINK + MIME
CONTRACTS * What do we promise our clients? * Read
these: - http://martinfowler.com/bliki/TolerantReader.html - http://martinfowler.com/articles/consumerDrivenContracts.html
SERIALIZED FORM + Easy programming (initially, typed proxies) - Rigid
(will not bend, will break)
SCHEMAS * Good for automated testing * If you give
them away, assume people will generate proxies (and depend on serialized form) * Consider not providing any (or model them loose, xs:any etc - I’m not sure it’s a good idea)
GUARANTEES * Fields annotated with “#userid” will have the following
form * Attributes named “email” will conform standard X * This document contains one, and only one field annotated “#id”, which is the unique id for Y
ROBUSTNESS
<user> <id>1234</id> <name> <first>Mårten</first> <last>Gustafson</last> </name> </user> * XPath
<user> <id>1234</id> <name> <first>Mårten</first> <last>Gustafson</last> </name> </user> /user/name/last * Rigid
<user> <id>1234</id> <name> <first>Mårten</first> <last>Gustafson</last> </name> </user> //last * Adaptive
* Might return multiple
<user> <id>1234</id> <name> <first>Mårten</first> <last>Gustafson</last> </name> </user> //last[1] * Adaptive
* Only one
<user> <id>1234</id> <name> <first id=”#name.first”>Mårten</first> <last id=”#name.last”>Gustafson</last> </name> </user> *
Annotated
<user> <id>1234</id> <name> <first id=”#name.first”>Mårten</first> <last id=”#name.last”>Gustafson</last> </name> </user> //last[1]
* Still works
<user> <id>1234</id> <name> <first id=”#name.first”>Mårten</first> <last id=”#name.last”>Gustafson</last> </name> </user> //*[@id='#name.last'][1]
* Adaptive
<user> <id>1234</id> <first id=”#name.first”>Mårten</first> <last id=”#name.last”>Gustafson</last> </user> //*[@id='#name.last'][1] * Still
works
<named> <first id="#name.first">Mårten</first> <last id="#name.last">Gustafson</last> </named> //*[@id='#name.last'][1] * Still works
<yeah> <foo id="#name.first">Mårten</foo> <bar id="#name.last">Gustafson</bar> </yeah> //*[@id='#name.last'][1] * Still works
INFORMATION MODELLING * This is hard, usually “versioning hard”
#name.first * Format * Values * Guarantees
URL DNS MIME LINKS PROXY
URL DNS MIME LINKS =CONTRACT
?
@martengustafson
[email protected]
http://marten.gustafson.pp.se/talks * Representations