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
630
The OPS side of DEV
chids
9
4.6k
[Swedish] NoSQL at Javaforum Stockholm
chids
2
170
Approaching and evaluating NoSQL
chids
3
180
Automation @ Hitta.se and why it happened
chids
1
270
Other Decks in Programming
See All in Programming
Go言語での実装を通して学ぶLLMファインチューニングの仕組み / fukuokago22-llm-peft
monochromegane
0
120
今だからこそ入門する Server-Sent Events (SSE)
nearme_tech
PRO
1
120
print("Hello, World")
eddie
2
530
Swift Updates - Learn Languages 2025
koher
2
470
個人軟體時代
ethanhuang13
0
320
@Environment(\.keyPath)那么好我不允许你们不知道! / atEnvironment keyPath is so good and you should know it!
lovee
0
110
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
500
テストカバレッジ100%を10年続けて得られた学びと品質
mottyzzz
2
580
RDoc meets YARD
okuramasafumi
4
170
1から理解するWeb Push
dora1998
7
1.9k
Kiroで始めるAI-DLC
kaonash
2
580
MCPとデザインシステムに立脚したデザインと実装の融合
yukukotani
4
1.4k
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
77
6k
Designing Experiences People Love
moore
142
24k
The Art of Programming - Codeland 2020
erikaheidi
56
13k
Done Done
chrislema
185
16k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Raft: Consensus for Rubyists
vanstee
140
7.1k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
A designer walks into a library…
pauljervisheath
207
24k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
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