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
360
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
330
Bastardised Kanban
chids
0
1.4k
Heroku as a production platform
chids
0
160
DevOps @ KnowIT
chids
0
150
Opinions on DevOps
chids
2
600
The OPS side of DEV
chids
9
4.5k
[Swedish] NoSQL at Javaforum Stockholm
chids
2
140
Approaching and evaluating NoSQL
chids
3
160
Automation @ Hitta.se and why it happened
chids
1
250
Other Decks in Programming
See All in Programming
GoとPHPのインターフェイスの違い
shimabox
2
180
Spring gRPC について / About Spring gRPC
mackey0225
0
220
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
36
14k
Lottieアニメーションをカスタマイズしてみた
tahia910
0
130
Formの複雑さに立ち向かう
bmthd
1
840
第3回関東Kaggler会_AtCoderはKaggleの役に立つ
chettub
3
1k
SwiftUI Viewの責務分離
elmetal
PRO
1
230
iOSエンジニアから始める visionOS アプリ開発
nao_randd
3
130
社内フレームワークとその依存性解決 / in-house framework and its dependency management
vvakame
1
560
2024年のWebフロントエンドのふりかえりと2025年
sakito
2
240
Amazon S3 TablesとAmazon S3 Metadataを触ってみた / 20250201-jawsug-tochigi-s3tables-s3metadata
kasacchiful
0
160
Grafana Cloudとソラカメ
devoc
0
170
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Navigating Team Friction
lara
183
15k
Designing Experiences People Love
moore
140
23k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
4 Signs Your Business is Dying
shpigford
182
22k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.3k
Mobile First: as difficult as doing things right
swwweet
223
9.3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
10
1.3k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Optimizing for Happiness
mojombo
376
70k
Building Adaptive Systems
keathley
40
2.4k
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