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: 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

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