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
350
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.3k
Heroku as a production platform
chids
0
140
DevOps @ KnowIT
chids
0
140
Opinions on DevOps
chids
2
580
The OPS side of DEV
chids
9
4.5k
[Swedish] NoSQL at Javaforum Stockholm
chids
2
120
Approaching and evaluating NoSQL
chids
3
150
Automation @ Hitta.se and why it happened
chids
1
220
Other Decks in Programming
See All in Programming
スキーマ駆動開発による品質とスピードの両立 - 私達は何故、スキーマを書くのか
kentaroutakeda
0
120
[技育CAMPアカデミア]アイディアを形に!【超入門】スマホアプリ開発〜リリースまでの流れをご紹介
teamlab
PRO
0
350
Git Lint
bkuhlmann
4
740
Git Rebase
bkuhlmann
11
1.6k
受託開発でGitLab CI を活用していく
xiombatsg
1
270
Java 22 Overview
kishida
1
170
ADRを一年運用してみた/adr_after_a_year
hanhan1978
7
2.2k
甘い香りに誘われてVanilla Extractを1年間運用してみた
miyahkun
1
110
Rails と人魚の話/rails-and-mermaid
sanfrecce_osaka
0
100
try! Swift Tokyo 2024 参加報告 / try! Swift Tokyo 2024 Report
hironytic
0
170
Javaエンジニアのための Nodejs/Nuxt3入門
hidekatsu_izuno
0
280
Site Reliability Engineering for GMO
pyama86
6
960
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
Agile that works and the tools we love
rasmusluckow
324
20k
We Have a Design System, Now What?
morganepeng
42
6.7k
Building a Scalable Design System with Sketch
lauravandoore
455
32k
Ruby is Unlike a Banana
tanoku
96
10k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3k
Optimising Largest Contentful Paint
csswizardry
7
2.3k
In The Pink: A Labor of Love
frogandcode
138
21k
Building Your Own Lightsaber
phodgson
98
5.7k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
220
21k
Why Our Code Smells
bkeepers
PRO
331
56k
Git: the NoSQL Database
bkeepers
PRO
422
63k
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