REST - Hyper Media klienter med Ramone
-
Upload
jornwildt -
Category
Technology
-
view
257 -
download
3
Transcript of REST - Hyper Media klienter med Ramone
Jørn Wildt, cBrain
REST - Hyper media
klienter med Ramone
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
REST – Et løfte om …
Skalérbarhed
God performance
Fleksibilitet
Løst koblede servere og klienter
Ramone – en REST/HTTP
klient
Nyt projekt – startet 2011
Open Source
https://github.com/JornWildt/Ramone
Mere om det senere …
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
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
REST –En arkitektonisk stilart
for software
Client – Server
Stateless
Layered System
Cacheable
Code On Demand
Uniform Interface
Dekobler ”data leverandører”
og ”data aftagere”
Frihed til uafhængig
udvikling af komponenter og
valg af platforme
REST –En arkitektonisk stilart
for software
Client – Server
Stateless
Layered System
Cacheable
Code On Demand
Uniform Interface
Serveren holder ikke styr på
klienterne og deres tilstand.
Klienten sender selv alt
nødvendig information i hver
forespørgelse.
Skalérbarhed af server
REST –En arkitektonisk stilart
for software
Client – Server
Stateless
Layered System
Cacheable
Code On Demand
Uniform Interface
Netværket mellem klient og
server kan indeholde
alverdens ekstra
komponenter.
Frihed til at forbedre
netværket uden at ændre
klient og server.
REST –En arkitektonisk stilart
for software
Client – Server
Stateless
Layered System
Cacheable
Code On Demand
Uniform Interface
Indbygget support for
caching af resultater fra
netværket.
Bedre performance
REST –En arkitektonisk stilart
for software
Client – Server
Stateless
Layered System
Cacheable
Code On Demand
Uniform Interface
Servere kan levere
eksekverbar kode til klienter.
Bedre performance
Fleksibilitet
REST –En arkitektonisk stilart
for software
Client – Server
Stateless
Layered System
Cacheable
Code On Demand
Uniform Interface
Ensartet og standardiseret
adgang til alle data.
(mere om det lige om lidt)
Uniform interface
Identification of
resources
Manipulation of
resources through
representations
Self-descriptive
messages
Hypermedia as the engine of application
state.
URI /URL
Distribueret og global
navngivning
(modsat tidligere tiders
”link servers”)
Uniform interface
Identification of
resources
Manipulation of
resources through
representations
Self-descriptive
messages
Hypermedia as the engine of application
state.
Abstraktion af data
Frihed til at ændre bagved
liggende implementering
Global fælles forståelse af
data via media types
Uniform interface
Identification of
resources
Manipulation of
resources through
representations
Self-descriptive
messages
Hypermedia as the engine of application
state.
Headers
(operation, host, content-
type, zip-encoding osv.)
Data kan forstås og
manipuleres i netværket
Fri for data gætværk
Uniform interface
Identification of
resources
Manipulation of
resources through
representations
Self-descriptive
messages
Hypermedia as the engine of application
state.
Links og forms
Frihed til at forbedre API
uden koordinering med alle
klienter
Fleksibilitet
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?
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
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 }
Knap så identificerbar
ressourceRequest (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 }
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
{ … }
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
… REKLAME …https://github.com/JornWildt/Ramone
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;
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!
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.
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 …
Twitter 1 – Hvor er mine links?
{
text : ”Hello world”,
user :
{
id : 1234
name : ”John”
}
}
Twitter 2 – Her kunne de være
{
text : ”Hello world”,
user :
{
link : ”http://api.twitter.com/...”,
name : ”John”
}
}
URL ”Navngivning” : ”user / link”.
Hyper media: link relationer
HTML
<a rel=”deltager” href=”…”>Deltager 1</a>
ATOM
<link rel=”deltager” href=”…” title=”Deltager 1” />
=> Tydelig navngivning af URL
Versionering: deltager v1
<deltager>
<navn>John</navn>
<link rel=”adresse”
href=”…”/>
</deltager>
Versionering: deltager v2
<deltager>
<navn>John</navn>
<link rel=”adresse”
href=”…”/>
<link rel=”bedre-adresse”
href=”…”/>
</deltager>
Service-index
<services>
<link rel=”kurser” href=”…”/>
<link rel=”tilmeldinger” href=”…”/>
<link rel=”deltagere” href=”…”/>
</services>
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!
… REKLAME …https://github.com/JornWildt/Ramone
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;
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.
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)
Hyper media: formularer
Klienten kender kun formularens
Identifikation
Parametre
På runtime finder klienten
HTTP metode
URL
Data format
=> Frihed til at forbedre server operationer
Formular v1: URL template
<form id=”deltager-søgning”
hreft=”/deltagere{?dnr}” />
Profilnavn = ”deltager-søgning”
Parametre:
dnr = deltagernummer
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!
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>
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!
… REKLAME …https://github.com/JornWildt/Ramone
Hyper media klient
Formularer
IKeyValueForm f
= GetForm(”deltager-søgning”);
f.Value(”dnr”, 1234);
Search s = f.Bind(Session)
.Submit<Search>();
Service kontrakt
En kontrakt som ejes af servicen
Klient Én
unik
Service
Kontrakt
Data
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
Fælles standard
ServiceService
Media type
Fælles kontrakt som ikke ejes af server
”Self descriptive messages”
Klient
Mange
ensartede
services
Media type
Data
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”
Konklusion …
Et paradigmeskift
Simpel data / smarte klienter
Smart data / simple klienter
Mindre klient/server kobling
Færre klient-opgraderinger
Fred, kærlighed og god karma
Kendte ulemper
Grovkornede operationer
Bruger mere båndbredde (data + metadata)
Manglende værktøjer på klientsiden ...
Et misforstået koncept ...
Det var (næsten) alt …
Kontakt
Jørn Wildt
E-Mail: [email protected]
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
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
Læs mere …
http://bit.ly/cd2012a1