OIOREST nyhedsbrev

Torsdag d. 5. november 2009

Mainstream

IT- og Telestyrelsen afholdt d. 28. september en OIOREST workshoppen Sådan får du Offentlige data i spil, hvis formål var at vise hvordan offentlige data kan udstilles vha. en OIOREST service. Workshoppen gik godt. Deltagerne var engagerede og spørgelystne. Men det var alligevel som om, at der manglede noget. Noget, som der plejede at være der, når vi afholdt OIOREST arrangementer. Der gik et stykke tid, inden jeg fandt ud af, hvad det var der var anderledes. Det var selvfølgelig fraværet af den sædvanlige ophidsede debat om REST kontra WS-*. Den dukkede ikke op på workshoppen.

Det er blot et af mange tegn på at konflikten mellem WS-* og REST er bilagt i fredelige sameksistens. Af andre indikationer på dette kan nævnes: Den Digitale Taskforce har taget OIOREST til sig. Snitfladerne til Dokumenboks/NemSMS baseres på OIOREST. Miljøportalen vælger at udstille deres offentlige data vha. OIOREST. Microsoft har midlertidigt sat WS-* udvikling i bero for at fokusere udviklingen på REST. Mine WS-* orienterede kollegaers venlige drillerier omkring OIOREST er nærmest forstummet ;). Alpha geeks’ene har forladt arena’en. Røgen har lagt sig. OIOREST er kort sagt blevet mainstream. Derfor ser OIOREST nu en mulighed for at præsentere sig, uden at skulle forholde sig til en kunstig, ørkesløs konflikt med sin webservice-søster SOAP. Scenen er sat. Lad os starte.

OIOREST er et initiativ fra IT- og Telestyrelsen, hvis mål er at fremme den web orienterede arkitektur - også kaldet WOA – i Det Digitale Danmark. Og ja, jeg ved, at det ikke er ypperste mode at tale om it-arkitekturer i øjeblikket, samt at der er nogle, der hævder at it-arkitektur er i bad standing. Jeg vil dog hævde, at den arkitektur vi vil behandle her, adskiller sig fra ”bad standing” arkitekturerne ved at have eksisteret og leveret succeser i omkring 20 år. Selvfølgelig kan en arkitektur misbruges eller bruges forkert og frembringe fiaskoer. Det er set, men set som en helhed, kan man vel ikke sige andet at webbet har været og er en succes, som tilbyder os mange forskellige services, information og data. OIOREST forsøger at motivere og inspirere Det Digitale Danmark til at lade deres applikationer, services og data deltage i webbets arkitektur, således at de kan blive fundet af webbets søgemaskiner og brugt af borgere, virksomheder, det offentlige samt af deres applikationer og services. Webbets arkitektur eksisterer og anvendes. Standarderne, værktøjerne og platformene til at materialisere webbets arkitektur findes i overflod. Brug dem!

Webbets arkitektur er baseret på den arkitektoniske stil REST.

Hvad er REST?

Da Internet Engineering Taskforce i midthalvfemserne skulle definere den eksisterende Hypertext Transfer Protocol (HTTP 1.0) og designe den kommende HTTP 1.1, så de et behov for en model til beskrivelse af hvordan World Wide Web (WWW eller webbet) skulle fungere. Denne model blev grundlaget for webbets arkitektur ved at give vejledende principper, der blev brugt til at finde svagheder i den eksisterende arkitektur og validere/vurdere kommende udvidelser til webbet. Modellen bliver refereret som den Representational State Transfer (REST) arkitektoniske stil.

Den første udgave af REST blev frembragt i årene 1994-1995 og blev primært brugt til kommunikation af web koncepter og validering i forbindelse med specifikation og validering af web standarder. Ideen med det lidt specielle navn Representational State Transfer var at fremkalde et billede af hvordan en vel designet web applikation opfører sig: et netværk af web sider der etablerer en virtuel tilstandsmaskine, der tillader brugeren at navigere sig gennem applikationen fra side til side ved at vælge link, hvor hver overgang mellem siderne bringer applikationen til næste tilstand ved at overføre (Transfer) en repræsentation (Representational) af denne tilstand (State) til brugeren. [Fielding 2002]

En software arkitektur er en abstraktion af elementerne i et softwaresystem på kørselstidspunktet. Arkitekturen bestemmer hvorledes systemets elementer identificeres, hvordan elementerne interagere for at skabe/forme systemet, granulariteten af den nødvendige kommunikation, samt protokollerne, der anvendes i kommunikationen.

En arkitektonisk stil er et sæt arkitektoniske principper, som begrænser de arkitektoniske elementers virkemåde, samt de tilladte relationer mellem disse elementer.

REST er et sæt arkitektoniske principper, hvis mål er at minimere latency og netværks kommunikation, samt maksimere uafhængigheden og skalerbarheden af implementeringerne. REST gør det muligt at cache og genbruge interaktioner, dynamisk substitution af komponenter, og udføre operationer vha. intermediaries for at opfylde behovet fra et distribueret hypermedia system i Internetskala.

REST principperne er oprindeligt defineret i Roy T. Fieldings Ph.D. afhandling [Fielding 2000], men klarere formuleret i [Fielding 2002]. Med inspiration fra [Tilkov 2007] og [Richardson 2007] har vi udmøntet REST principperne på følgende måde i OIOREST:

1. Giv alle ting (ressourcer) en URI

Muligheden for at kunne identificere ting med URI/URL er grundlaget for internettet. Hvis du giver en permanent URI/URL til dine data vil det muliggøre at systemer og mennesker lettere er i stand til at finde dem og bruge dem. URI/URL kan bruges som universale, unikke identifikationer (id’er).

En ressource er alt hvad der er vigtigt nok til at blive refererer som en ting i sig selv. Normalt er en ressource noget, som kan blive lagret på en computer og repræsenteret som bits, et dokument, en række i en database eller resultatet af en beregning. Alle ressourcer skal navngives vha. en URI. En URI bør beskrive den ressource den adresserer.

Eksempler på ressourcer og beskrivende URI’er taget fra OIOREST demo servicerne Danmark og FindFisken:

  1. Københavns kommune: http://oiorest.dk/danmark/kommuner/101
  2. Sorgenfri slot: http://oiorest.dk/danmark/kommuner/173/lokaliteter/Sorgenfri Slot
  3. Dronningens adresse: http://oiorest.dk/danmark/adresser/Amalienborg Slotsplads,2,1257
  4. Region Hovedstaden: http://oiorest.dk/danmark/regioner/1085
  5. Ørred: http://oiorest.dk/findfisken/arter/206
  6. Feltprøver med ørred i Ringkøbing-Skjern kommune: http://oiorest.dk/findfisken/feltprøver?kommunenr=760&artsnr=206

En service skal vha. URI/URL adressere ethvert stykke information, som den er designet til at udstille. Dette er normalt et stort antal URI/URL. For Danmark servicen vedkommende drejer det sig om flere millioner universale, unikke identifikationer.

2. Link tingene(ressourcerne) til hinanden

Ressourcer bør linke til hinanden. Repræsentationer indeholder i de fleste tilfælde ikke kun data, men også links til andre ressourcer, som er identificeret vha. URI/URL. Der er fire forventninger til disse URI/URL:

  1. URI er navne for ting
  2. URI/URL hjælper med at finde disse ting
  3. Når man følger URI/URL’en skal man finde brugbar information
  4. Link i dine data hjælper med at opdage flere relaterede ting/informationer

Nedenfor er der en repræsentation af ressourcen prøvestationen v/Gjaldbæk Bro(http://oiorest.dk/findfisken/stationer/2000012) fra FindFisken servicen.

Repræsentation af prøvestation

Repræsentationen indeholder data om pågældende prøvestation, men også link til relaterede data. Der er f.eks. et link til de feltprøver, der er taget på prøvestationen. Endvidere er der et link til hvilken kommune prøvestationen ligger i. Dette link peger ud af FindFisken applikationen og over i Danmarkservicen. Resultatet af at følge dette link ses nedenfor:

Repræsentation af Ringkøbing kommune

I repræsentationen af kommunen findes data om kommunen, samt links til relaterede ressourcer: hvilken region kommuner er indeholdt i, kommunens veje, adresser, skoledistrikter, skoler, valgdistrikter, geografisk grænse samt endelig et link til ressourcen selv.

Både FindFisken- og Danmarkservicen er desværre kun demoservices. Det ville være en fordel, hvis væsentlige ting i Danmark havde deres permanente URL, som kunne tilgås med det resultat at man fik information om tingen og relaterede ting. Det kunne være kommuner, postdistrikter, kirker, borgercentre osv. Det ville være en fordel, hvis data var tilgængelige som REST services hos deres dataejer, så andre kunne tilgå disse, frem for at de hver især skulle finde data, og hvis de er fandtes kopiere dem over i eget system, skabe relationer til relaterede data, samt holde øje med hvornår de bliver opdateret for så at gentage processen.

3. Alle ressourcer tilgås via samme interface

Der kan kun udføres meget få operationer på en ressourcer og det er samme operationer for alle webbets ressourcer. Det kaldes princippet om det uniforme interface. HTTP rummer fire basale metoder for de mest almindelige operationer:  

Metode Beskrivelse Egenskaber
GET Modtag repræsentation af ressource (muligvis cached) safe, idempotent, cacheable
PUT Opdater eller opret en ressource med kendt id. idempotent
DELETE Slet en ressource idempotent
POST Opret en ressource

Udover ovenstående metoder rummer HTTP også de mindre brugte metoder: OPTIONS, HEAD, TRACE og CONNECT.

Anvendelse af en safe metode (GET og HEAD) er et forespørgelse til at læse data, ikke til at ændre data. En safe metode kan godt have sideeffekter, men det er udelukkende serverens ansvar. Klienten har ikke anmodet om disse sideeffekter og kan ikke gøres ansvarlig for dem.

Idempotence-begrebet stammer fra matematikken. En idempotent operation er en operation , som har samme effekt uanset hvor mange gange du udfører operationen. F.eks. er multiplikation med 1 en idempotent operation: 42 * 1 * 1* 1 er det samme som 42 * 1. En operation på en ressource er idempotent, hvis det er det samme at lave et request som at lave en række identiske request. GET, PUT og DELETE er idempotente metoder. Uanset hvor mange gange du sletter en ressource med DELETE metoden er den slettet. Uanset hvor mange gange du anvender PUT til at oprette eller opdatere en ressource, vil den efter hver operation være oprettet eller opdateret.

Grunden til at safe og idempotence er vigtige egenskaber, er at det giver klienten mulighed for at etablere pålidelig kommunikation over et upålideligt netværk. Hvis du laver et GET request, hvor du aldrig får et svar, laver du bare et nyt request indtil du får et succesfuldt. Hvis du laver et PUT request og aldrig får et svar, gentager du requestet indtil du får et succesfuldt. Hvis dit tidligere request gik igennem til serveren uden du fik svar, vil et andet request ikke gøre nogen forskel på serverens tilstand.

Fordelen ved et et uniformt interface er at alle ressourcer på webbet kan tilgås med de samme metoder. Hvis du får en URI vil du altid kunne få en repræsentation af ressorcen ved at sende et GET request til URI’en.

4. Tillad forskellige repræsentationer af samme ressource

I kommunikationen mellem klient og server er det ikke ressourcen, som bliver kommunikeret, men en repræsentation af den. En repræsentation af ressource kan f.eks. være udtrykt i følgende formater XML, HTML, CSV, JPEG og JSON.

Hvis en ressource repræsenteres i flere forskellige formater, hvordan finder serveren ud af hvilken repræsentation klienten ønsker. Der findes flere metoder. En af dem er Content negotiation , hvor klienten i HTTP request headere engiver hvilken repræsentation den ønsker. En anden og den simpleste metode, som OIOREST anbefaler, er at give hver repræsentation sin egen URI, da de fleste klientapplikationer ikke ønsker at forhandle om formatet, men ønsker et bestemt format.

Eksempel: I Danmark servicen har ressourcen Sorgenfri slots adresser følgende repræsentationer (bemærk at suffixet til URL’en angiver repræsentationen):

5. Kommuniker tilstandsløs

Med tilstandsløs kommunikation menes, at hvert eneste HTTP request sker i komplet isolation. Når klienten laves et HTTP request til serveren, inkluderer den al den information, der er nødvendig for serveren til at udføre requestet. Serveren afhænger ikke af information fra tidligere request, men kun af information fra selve requestet og de udstillede ressourcer.

Tilstandsløs kommunikation gør det lettere at skalere sin løsning (sæt flere servere op i load balancer’en), samt at debugge, da hvert request rummer den information, der skal til for at udføre requestet.

Referencer

[Fielding 2000]: Roy Fielding, Architectural Styles and the Design of Network-based Software Architectures, University of California, Irvine, 2000 http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[Fielding 2002]: Roy Fielding and Richard N. Taylor, Principled Design of the Modern Web Architecture, ACM Transactions on Internet Technology, Vol. 2, no. 2, May 2002, pages 115-150.

[Richardson 2007]: Richardson, Leonard and Sam Ruby, RESTful Web Services, O’REILLY, 2007

[Tilkov 2007]: Stefan Tilkov, A Brief Introduction to REST, infoq.com 2007 http://www.infoq.com/articles/rest-introduction

Det var enden på et lidt langt nyhedsbrev. For de få trofaste læsere, der har fulgt mig hertil, vil jeg lige fortælle, at i næste nyhedsbrev vil vi se på udfordringerne, der er i at anvende offentlige data. Vi tager udgangspunkt i et konkret eksempel.

Finn Jordal / @OIOREST

IT- og Telestyrelsen