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
What's new in AppKit on macOS 26
1024jp
0
170
Googleの新しいコーディングAIエージェントJulesを使ってみた
tonionagauzzi
0
130
[SRE NEXT] 複雑なシステムにおけるUser Journey SLOの導入
yakenji
0
790
フロントエンドのパフォーマンスチューニング
koukimiura
6
2.3k
Gemini CLIの"強み"を知る! Gemini CLIとClaude Codeを比較してみた!
kotahisafuru
2
180
Android 16KBページサイズ対応をはじめからていねいに
mine2424
0
670
Vibe Codingの幻想を超えて-生成AIを現場で使えるようにするまでの泥臭い話.ai
fumiyakume
18
9.4k
テスト駆動Kaggle
isax1015
1
890
AI Agent 時代のソフトウェア開発を支える AWS Cloud Development Kit (CDK)
konokenj
6
990
The Niche of CDK Grant オブジェクトって何者?/the-niche-of-cdk-what-isgrant-object
hassaku63
1
710
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
560
効率的な開発手段として VRTを活用する
ishkawa
1
180
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Mobile First: as difficult as doing things right
swwweet
223
9.7k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
720
How to train your dragon (web standard)
notwaldorf
96
6.1k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Being A Developer After 40
akosma
90
590k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
We Have a Design System, Now What?
morganepeng
53
7.7k
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