1. REST - Hyper media
klienter med Ramone
Jørn Wildt, cBrain

2. Mig?
 Jørn Wildt (1970)
 Softwareudvikler siden 1985
 Open Source udvikler siden 1994
 Unix Commander (studietid)
 BuDDy (Phd.)
 Zikula CMS, tidl. PostNuke (2004 – 2009)
 Ramone (2011 - ????)
 Ansat hos cBrain (2004 - ...)
 Far til Erik (4½ år) og Line (½ år)
 Andet – klatring, løb, havkajak, skiløb

3. REST – Et løfte om …
 Skalérbarhed
 God performance
 Fleksibilitet
 Løst koblede servere og klienter

4. Ramone – en REST/HTTP
klient
 Nyt projekt – startet 2011
 Open Source
https://github.com/JornWildt/Ramone
 Mere om det senere …

5. Fra WEB Browser til REST
API
 Tim Bernes-Lee 1990
 World Wide Web (HTTP 0.9)
 Roy T. Fielding mf. 1997
 HTTP 1.1
 Roy T. Fielding 2000 (PhD. Afhandling)
 REST - REpresentational State Transfer
 Fra SOAP til REST 20XX
 RESTful Web Services

6. Denne præsentation …
 Fokus på at implementere
 ”Machine-to-machine” systemer med
 Løst koblede,
 Frie og uafhængige,
 Selvstændige,
 Klienter og servere,
 Der kan forbedres løbende uden pjat!
 Mindre snak om performance og
skalering

7. REST –En arkitektonisk stilart
for software
 Client – Server
 Stateless
Dekobler ”data leverandører”
og ”data aftagere”
 Layered System
 Frihed til uafhængig
 Cacheable
udvikling af komponenter og
valg af platforme
 Code On Demand
 Uniform Interface

8. REST –En arkitektonisk stilart
for software
 Client – Server
Serveren holder ikke styr på
 Stateless
klienterne og deres tilstand.
 Layered System
Klienten sender selv alt
nødvendig information i hver
 Cacheable
forespørgelse.
 Code On Demand
 Skalérbarhed af server
 Uniform Interface

9. REST –En arkitektonisk stilart
for software
 Client – Server
Netværket mellem klient og
 Stateless
server kan indeholde
alverdens ekstra
 Layered System
komponenter.
 Cacheable
 Frihed til at forbedre
netværket uden at ændre
 Code On Demand
klient og server.
 Uniform Interface

10. REST –En arkitektonisk stilart
for software
 Client – Server
 Stateless
Indbygget support for
 Layered System caching af resultater fra
netværket.
 Cacheable
 Bedre performance
 Code On Demand
 Uniform Interface

11. REST –En arkitektonisk stilart
for software
 Client – Server
 Stateless
Servere kan levere
eksekverbar kode til klienter.
 Layered System
 Bedre performance
 Cacheable
 Fleksibilitet
 Code On Demand
 Uniform Interface

12. REST –En arkitektonisk stilart
for software
 Client – Server
 Stateless
 Ensartet og standardiseret
 Layered System
adgang til alle data.
 Cacheable
(mere om det lige om lidt)
 Code On Demand
 Uniform Interface

13. Uniform interface
 Identification of
resources URI /URL
 Manipulation of  Distribueret og global
resources through navngivning
representations (modsat tidligere tiders
”link servers”)
 Self-descriptive
messages
 Hypermedia as the engine of application
state.

14. Uniform interface
 Identification of
resources Abstraktion af data
 Manipulation of  Frihed til at ændre bagved
resources through liggende implementering
representations  Global fælles forståelse af
data via media types
 Self-descriptive
messages
 Hypermedia as the engine of application
state.

15. Uniform interface
 Identification of
resources Headers
(operation, host, content-
 Manipulation of type, zip-encoding osv.)
resources through  Data kan forstås og
manipuleres i netværket
representations
 Fri for data gætværk
 Self-descriptive
messages
 Hypermedia as the engine of application
state.

16. Uniform interface
 Identification of
resources Links og forms
 Manipulation of  Frihed til at forbedre API
resources through uden koordinering med alle
klienter
representations
 Fleksibilitet
 Self-descriptive
messages
 Hypermedia as the engine of application
state.

17. Man ser et mønster …
 Frihed til uafhængigt at ændre servere
og klienter
 Fælles forståelse for data
 Skalérbarhed
 Performance
Vi kender det fra HTML/browser.
Kan vi få samme effekter for vores API’er?

18. Hvad er der "normalt” styr på?
 Performance
 Skalérbarhed
 Frihed til uafhængigt at ændre servere
og klienter
 Identificerbare ressourcer
 Hyper media
 Fælles forståelse for data
 Media types

19.  Identificerbar ressource
Request (http://api.cdcph.dk/deltagere/1234):
GET /deltagere/1234 HTTP/1.1
Response
Content-Type: application/json
{ navn: ”John”, deltagerNr: 10, id: 1234 }

20.  Knap så identificerbar
ressource
Request (http://api.cdcph.dk/deltagere):
POST /deltagere?action=read&id=1234
POST /deltagere?action=afmeld&id=1234
Skjult semantik (HTTP tunnelling)
Response
Content-Type: application/json
{ navn: ”John”, deltagerNr: 10, id: 1234 }

21. Fra handling til ressource
 Request 1 (http://api.cdcph.dk/deltagere)
POST /deltagere
{ action = ”tilmeld”, nummer = 1234, … }
 Request 2 (http://api.cdcph.dk/deltagere/1234/tilmeldinger)
POST /deltagere/1234/tilmeldinger
{…}

22. Barometercheck!
 Skift fra mange ukendte handlinger og
meget få ressourcer
 Til standard handlinger og mange
(endnu ukendte) ressourcer
 Giver
 Fælles forståelse af data-tilgang og dermed
 Bliver det
 Standardiseret API for ALLE services, og
 Færre linjer kode

23. … REKLAME …
https://github.com/JornWildt/Ramone

24. Standard API / standard C# klient
?
 Identificerbare ressourcer
 Standard operationer (GET/POST/…)
Request rq = DeltagerUrl.Bind(Session);
Response<Deltager> rs = rq.Get<Deltager>();
Deltager d = rs.Body;
// Alternativt for JSON data
// dynamic deltager = rs.Body;

25. RESTful URL’er? Nonsens!
 http://example.com/examples/1234
 http://example.com/examples?id=1234
 http://example.com/examples.1234.json
 http://example.com/jiourjlw-576-cd
 Alle URL’er er skabt lige, og
 Ingen URL’er er mere RESTful end
andre.
 Og strukturen er hamrende ligegyldig!

26.  Prædefinerede stier
Klassisk API dokumentation (Twitter)
GET /statuses/home_timeline
Returns the most recent statuses, including
retweets if they exist …
Herefter og i al evighed er denne
sammenhæng låst.

27.  Navngivne URL’er
RESTful dokumentation
GET {timeline-url}
Returns the most recent statuses, including
retweets if they exist …
Selve URL’en findes først på runtime.
=> Frihed til at ændre informations-struktur
Og hvordan gør vi så det? Lad os se et eksempel …

28. Twitter 1 – Hvor er mine links?
{
text : ”Hello world”,
user :
{
id : 1234
name : ”John”
}
}

29. Twitter 2 – Her kunne de være
{
text : ”Hello world”,
user :
{
link : ”http://api.twitter.com/...”,
name : ”John”
}
}
URL ”Navngivning” : ”user / link”.

30. Hyper media: link relationer
 HTML
 <a rel=”deltager” href=”…”>Deltager 1</a>
 ATOM
 <link rel=”deltager” href=”…” title=”Deltager 1” />
=> Tydelig navngivning af URL

31. Versionering: deltager v1
<deltager>
<navn>John</navn>
<link rel=”adresse”
href=”…”/>
</deltager>

32. Versionering: deltager v2
<deltager>
<navn>John</navn>
<link rel=”adresse”
href=”…”/>
<link rel=”bedre-adresse”
href=”…”/>
</deltager>

33. Service-index
<services>
<link rel=”kurser” href=”…”/>
<link rel=”tilmeldinger” href=”…”/>
<link rel=”deltagere” href=”…”/>
</services>

34. Barometercheck!
 Skift fra handlinger til ressourcer,
 Fra statiske URL’er til navngivne URL’er, og
 Anvendelse af hyper media
 Giver
 Fælles forståelse af data-tilgang
 Data som kan findes af alle
 Friheden til at serveren kan
○ Ændre informations-struktur (endda servere), og
○ Tilføje nye ressourcer
 Uden at opgradere klienter!

35. … REKLAME …
https://github.com/JornWildt/Ramone

36. Hyper media klient
 Navigering via hyper links
Request rq = DeltagerUrl.Bind(Session);
Response<Deltager> rs = rq.Get<Deltager>();
Deltager d = rs.Body;
Adresse a = d.Links.Select(”adresse”)
.Follow(Session)
.Get<Adresse>()
.Body;

37.  Prædefinerede opdateringer
Klassisk API dokumentation (Twitter)
POST statuses/update
Updates the authenticating user's status, also
known as tweeting … parameters are: …
Klient og server for evigt låst fast i denne
sammenhæng.

38.  Dynamiske operationer
Fleksibel dokumentation
{metode}
{url}
{format}
{parameter-1} … {parameter-N}
Updates the authenticating user's status, also
known as tweeting …
Alle oplysninger findes på runtime
(men parametre er domain specifikke)

39.  Hyper media: formularer
 Klienten kender kun formularens
 Identifikation
 Parametre
 På runtime finder klienten
 HTTP metode
 URL
 Data format
=> Frihed til at forbedre server operationer

40. Formular v1: URL template
<form id=”deltager-søgning”
hreft=”/deltagere{?dnr}” />
 Profilnavn = ”deltager-søgning”
 Parametre:
 dnr = deltagernummer

41. Formular v2: POST + redirect
<form id=”deltager-søgning”
href=”/deltagere-search”
method=”POST”
type="app…/…urlencoded"/>
 Profilnavn = ”deltager-søgning”
 Parametre:
 dnr = deltagernummer Uændret
Klientviden!

42. Server-drevet applikations-
flow
<deltager>
<navn>John</navn>
<!-- Findes kun hvis tilmeldt -->
<link rel=”afmeld-her” href=”…”/>
<!-- Findes kun hvis ej betalt -->
<link rel=”betal-her” href=”…”/>
<!-- Findes kun hvis man har adgang -->
<link rel=”persondata” href=”…”/>
</deltager>

43. Barometercheck!
 Skift fra handlinger til ressourcer, og
 Anvendelse af
 Hyper media,
 Formularer, og
 Server-drevet applikations-flow
 Giver
 Fælles forståelse af data-tilgang,
 Data som kan findes af alle
 Friheden til at serveren kan
○ Ændre informations-struktur (endda servere),
○ Tilføje nye ressourcer, og
○ Styre applikations-flowet
 Uden at opgradere klienter!

44. … REKLAME …
https://github.com/JornWildt/Ramone

45. Hyper media klient
 Formularer
IKeyValueForm f
= GetForm(”deltager-søgning”);
f.Value(”dnr”, 1234);
Search s = f.Bind(Session)
.Submit<Search>();

46. Service kontrakt
 En kontrakt som ejes af servicen
Kontrakt
Klient Data Én
unik
Service

47.  Service beskrivelse
 Beskriver URL’er og data
 GET /statuses/home_timeline
 Parametre: …
 Returværdier: …
 Er bundet til én implementering
 Ingen hyper media
 Alt er givet og hardkodet på forhånd
 Er svær at genbruge

48. Media type
 Fælles kontrakt som ikke ejes af server
 ”Self descriptive messages”
Media type
Fælles standard
Mange
Klient Data ensartede
Service
services
Service

49.  Media type beskrivelse
 Beskriver relationer og data
 <link rel=”…” href=”…”/>
 Forms parametre: …
 Dataformat: …
 Er ikke bundet til nogen implementering
 Anvender hyper media
 Alt bindes samme på runtime
 Er klar til genbrug
 Et registreret ID ”application/my-domain”

50. Konklusion …

51. Et paradigmeskift
Simpel data / smarte klienter
Smart data / simple klienter
Mindre klient/server kobling
Færre klient-opgraderinger
 Fred, kærlighed og god karma

52. Kendte ulemper
 Grovkornede operationer
 Bruger mere båndbredde (data + metadata)
 Manglende værktøjer på klientsiden ... 
 Et misforstået koncept ...

53. Det var (næsten) alt …

54. Kontakt
 Jørn Wildt
 E-Mail: jw@fjeldgruppen.dk
 Twitter: @JornWildt
 Blog: soabits.blogspot.com/
 LinkedIn: dk.linkedin.com/in/jornwildt
 Hjemmeside (gammel): www.elfisk.dk
 cBrain: www.cbrain.dk
 https://github.com/JornWildt/Ramone

55. Ramone 1.0
 Mange services => én klient 
 Uniform interface
 Identifiable resources
 Hyper media
○ Links (og templates)
○ Formularer
 Media type codecs
○ XML, JSON, HTML, Multipart, UrlEncoded, ...
○ Domain specifikke
 OAuth1 + Basic auth

56. Læs mere …

57. http://bit.ly/cd2012a1