195
ReST on arkkitehtuurityyli, joka tähtää yhteentoimivuuden säilyttämiseen sellaisissa hajautetuissa (hypermedia)järjestelmissä, joissa eri osapuolet kehittyvät ja muuttuvat itsenäisesti toisistaan riippumatta. ReSTin isä on Roy Fielding, joka esittelee tämän arkkitehtuurityylin väitöskirjassaan Architectural styles and the design of network-based software architectures, University of California, 2000. Katso myös esim. ReST Wiki, jossa ReST on kuvattu kompaktisti ja pääpiirteittäin. Myöhemmin kiinnostus ReSTiä kohtaan on kasvanut laajemminkin ja sitä pidetäänkin vaihtoehtoisena tapana toteuttaa löyhästi sidottuja palvelupohjaisia järjestelmiä. Toisaalta ReSTiä käytetään usein pilvipalveluissa tai tarkemmin kommunikoitaessa niiden kanssa. 196
ReST tulee sanoista Representational State Trasfer. Näistä sanoista ensimmäinen (representational) viittaa ReSTin avainkäsitteen resurssin esitysmuotoon. Resurssit puolestaan voivat olla mitä tahansa kiinnostuksen kohteita (vrt. substantiivit) verkossa, joihin voidaan viitata yksikäsitteisellä tavalla. ReSTissä tämä viittaustapa on URIt. Yhdellä resurssilla voi olla useita esitysmuotoja. Tilan (state) käsite on myös oleellinen. Itse resurssilla on tila (palvelimella) ja myös asiakassovelluksella on tila. ReST-kutsuilla käytännössä muutetaan resurssin ja asiakkaan tilaa: asiakkaat voivat päivittää resurssin tilaa ja toisaalta asiakkaiden omaa tilaa voidaan päivittää resurssilta haetun datan perusteella. Kaikki kutsut eivät kuitenkaan välttämättä muuta resurssin tilaa. Tällaisia siinä mielessä turvallisia kutsuja ovat esim. tiedon haut. 197
REST määrittelee joukon rajoitteita, joita noudattamalla yhteentoimivuus eri resurssien välillä voitaisiin taata. Jokaisella resurssilla tulee ensinnäkin olla yksikäsitteinen osoite, joka annetaan hypermedialinkkien käyttämän yleisen syntaksin avulla. Tämän avulla resurssit ovat tunnistettavissa ja niihin voidaan viitata. REST-pohjaiset järjestelmät nojautuvat tyypillisesti (mutta eivät välttämättä) HTTP:n käyttöön, jolloin resurssien yksikäsitteiset osoitteet annetaan URIen avulla. Lisäksi ReSTin kaikilla resursseilla tulee olla samanlainen rajapinta. Tässä(kin) suhteessa ReST siis poikkeaa Web-palvelukonseptista, jossa jokainen palvelu (tai palvelun tarjoaja) määrittelee oman rajapintansa (esim. operaatiot, joita voidaan kutsua). ReSTissä taas operaatiojoukko on määrätty. Tällöin myös niiden semantiikka on tunnettu. ReSTissä sanomina ovat resurssien tilojen muutokset tai kyselyt. ReSTissä käytetään tyypillisesti XML:ää standardiformaattina datalle. Tästä johtuen ReSTin voidaan ajatella keskittyvän datan siirtämiseen resurssien välillä, kun taas esimerkiksi Web-palvelut kuljettavat XMLformaattiin muunnettuja operaatiokutsuja SOAP-kirjekuoressa esimerkiksi HTTPyhteyden yli. Näin ollen voidaan edelleen myös sanoa, että ReSTissä data on kommunikaatiossa avainasemassa operaatioiden sijaan. Tästä syystä myös se soveltuu hyvin pilvipalveluratkaisuihin, jotka ainakin periaatteessa ovat jokseenkin dataorientoituneempia kuin operaatio-orientoituneet Web-palvelut. 198
Viimeinen rajoite (hypermedia as the engine of application state) tarkoittaa käytännössä sitä, että palvelimelta saadut vastaukset sisältävät URIt kaikkeen mitä voidaan seuraavaksi tehdä. Tämän ymmärtämiseksi kannattaa ajatella Webiä ja erityisesti HTML-dokumentteja. Tämän rajoitteen vuoksi sovellusta voidaan ajatella tilakoneena, jossa jokainen sivu on tila ja linkit edustavat mahdollisia tilasiirtymiä kyseisellä hetkellä aktiivisesta tilasta. 199
Kuten aiemmin todettiin, ReSTissä tavoitteena on määrätyt ja universaalit resurssien/palveluiden rajapinnat ja niiden tarjoamat operaatiot. HTTP:n käyttö ReSTin näkökulmasta tarjoaakin vastaukset tärkeisiin tavoitteisiin: standardiin nojautuminen ja määrätty operaatiojoukko. Nämä puolestaan implikoivat sen, että operaatioiden semantiikka on tunnettu. Nämä operaatiot vastaavat tietokantateknologioista tuttuja nk. CRUD-operaatioita: luo/lisää (create), lue (read), päivitä (update) ja tuhoa (delete). HTTP tarjoaakin operaatiot put, get, post ja delete tätä varten. Toisenlaisena analogiana tälle määrätylle operaatiojoukolle ovat tutut leikkaa ja liimaa operaatiot. Tällöin HTTP:n putoperaatio vastaa operaatiota luo (create) tai kopioi päälle (paste over), getoperaatio vastaa operaatiota lue (read) tai kopioi (copy), post-operaatio vastaa operaatioita päivitä (update) tai kopioi loppuun (paste after) ja deleteoperaatio vastaa tuhoa (delete) tai leikkaa (cut) operaatiota. 200
Tällä ja seuraavalla kalvolla on käsitelty ReSTiä ja HTTP-operaatioita hieman tarkemmin. Jokaisen operaation kohdalla on myös mainita sen (a) turvallisuudesta (safe/unsafe) ja (b) toistojen samankaltaisuudesta (idempotent/not idempotent). Näistä ensimmäinen viittaa siihen, muuttaako operaatio resurssin tilaa. Jälkimmäinen (idempotent) on matematiikastakin tuttu termi (idempotent: a mathematical quantity which when applied to itself under a given binary operation (as multiplication) equals itself (Marriam-Webster)), joka kuitenkin tässä sen yleisemmän tulkinnan mukaan kuvaa sitä, onko ko. operaatiokutsu samalla tavalla mahdollinen yhdelle kuin esimerkiksi kymmenelle muullekin. 201
ReSTissä on myös useita protokollaa koskevia rajoitteita. Ensimmäinen tällainen rajoite Client/Server mallin käyttö, koska se (ainakin periaatteessa) yksinkertaistaa toteutusta, vähentää kutsujen semantiikan kompleksisuutta, parantaa tehokkuutta ja lisää skaalautuvuutta. Toisena vaatimuksena on tilattomuus (stateless). Tämä saattaa kuulostaa oudolta, koska tila (state) on osa itse akronyymia (ReST). Tämä rajoite tarkoittaa kuitenkin sitä, protokolla on tilaton. Esim. minkäänlaista implisiittistä tilaa ole piilotettu peräkkäisten interaktioiden välille. Toisin sanoen, kaikki tarvittava informaatio kuljetetaan viesteissä. Kolmantena vaatimuksena on mahdollisuus välimuistin käyttöön (cacheable). Viimeisenä vaatimuksena on se, että protokolla koostuu kerroksista (layered). Tällöin palvelimen ja asiakkaan välille voidaan asettaa esim. palomuureja, proxyja/välityspalvelimia muuttamatta rajapintoja palvelimen ja asiakkaan välillä. Tämän asti mainittujen rajoitteiden lisäksi ReSTiin kuuluu myös muita rajoitteita, joita kaikkia ei tässä käydä läpi. Yhtenä jäljellä olevista rajoitteista mainittakoon kuitenkin optionaalinen rajoite, joka sallii koodin (kuten appletit tai skriptit) käytön asiakkaan toiminnallisuuden laajentamiseksi ja parantamiseksi. 202
203
WWW on ehkä tunnetuin esimerkki ReST-periaatteiden mukaista arkkitehtuurityyliä noudattavasta järjestelmästä. Ensinnäkin se koostuu HTTP:stä, sisältötyypistä (esim. HTML) sekä muista Internet-teknologioista kuten DNS. HTML-dokumentti voi puolestaan sisältää koodia (esim. javascriptkoodia tai appletteja) ja näin ollen tukee code-on-demand periaatetta. Lisäksi HTTP:llä on yleinen ja kaikille sama rajapinta resurssien osoittamiseen ja eri resurssien yksikäsitteiset osoitteet annetaan URI-osoitteina. 204
ReSTissä on etujensa lisäksi myös puutteita. Yksi oleellisimmista on viestinvälityksen turvaaminen. Tässä Web-palvelukonsepti on huomattavasti pidemmällä. Joitain WS-Securityn ratkaisuja on harkittu hyödynnettäväksi myös ReST-puolella. Lisäksi WSDL:ää vastaavaa palveluiden kuvauskieltä on odotettu jo jonkin aikaa. WADL pyrkii vastaamaan tähän haasteeseen. Sen suosio onkin lisääntynyt nopeasti. Se on osittain myös vastine Web-palvelukonseptin koreografia- ja orkestraatiokielille tarjoamalla tuke palveluiden yhdistämiselle. WADL-kieltä käsitellään seuraavaksi. 205
ReSTiä kuten niin monta muutakin teknologiaa, arkkitehtuurityyliä jne. käytetään myös paljon väärin. Tämä näkyy esimerkiksi siinä, että dataorientoitunutta ajattelutapaa ei olla oikein sisäistetty. Se onkin usein hankalaa, varsinkin operaatio-orientoituneeseen ajattelutapaan tottuneille. Lisäksi ReSTin rajoitteita ei aina ymmärretä oikein. Tällä kalvolla on lueteltu Markku Laitkorven esittämiä happotestejä, jotka ovat hyödyllisiä ReSTimäisyyden toteamiseksi. Hän esitteli nämä happotestit syksyn 2008 kurssitoteutuksessa vierailuluennollaan. 206
Hyviä ReST-esimerkkejä löytyy toki muitakin. Kannattaa esimerkiksi tutustua Atom Publishing Protocol (a.k.a. APP a.k.a. AtomPub ) esimerkkiin. Se on yksinkertainen HTTP-pohjainen protokolla Web-resurssien luomista ja päivittämistä varten. Se kehitettiin alun alkaen vaihtoehdoksi RSS:lle. Aiheeseen liittyen löytyy paljon esim. blogeja. Myös esimerkiksi Numbler on tutustumisen arvoinen. 207
208
209
210
211
Tämä osio perustuu pääosin WADL spesifikaatioon (Marc J. Hadley, Sun Microsystems) WADL on XML-pohjainen kieli verkkosovellusten kuvaamiseksi. Verkkosovellukset ovat puolestaan WADL-spesifikaation mukaan sovelluksia, jotka Pohjautuvat Web-arkkitehtuuriin ja infrastruktuuriin, Ovat riippumattomia ohjelmointikielestä ja alustasta, Tukevat sovellusten (uudelleen)käyttöä laajemmin kuin vain selaimen välityksellä, Mahdollistavat yhdistämisen muiden Web- ja desktop-sovellusten kanssa ja Edellyttää sisällön ja ennen kaikkea esitysmuodon (representations) semantiikan selkeyttä. WADLin terminologia on linjassa ReST-terminologian kanssa. Osittain senkin vuoksi se onkin nopeasti kasvattanut suosiotaan ReST-palveluiden kuvauskielenä. 212
WADL-spesifikaatio esittelee muutamia Web-sovelluksien kuvauskielelle tärkeitä ominaisuuksia, jotka on myös huomioitu WADL-kielessä. Nämä neljä omaisuutta kuvaavatkin WADLin perusominaisuudet hyvin: Resurssijoukko: kuten sivukartta, kuvaa käytettävissä/kutsuttavissa olevat resurssit Resurssien suhteet: kuvaa resurssien väliset suhteet (referenssit, järjestykseen liittyvät) Operaatiot, joilla resursseja voidaan kutsua: tuetut HTTP-operaatiot, niiden input/output sekä niiden tuetut formaatit Resurssin kuvaustavat (formaatit): Tuetut MIME-tyypit ja skeemat. Skeemat voidaan antaa XML Scheman tai RelaxNG:n avulla. 213
WADL-dokumentin rakenne on melko yksinkertainen. Seuraavaksi katsotaan tarkemmin method-, representation-, fault ja jresource_type rakenteita. 214
215
216
217
218
219
220
Työkalutukea WADLille on jo olemassa. Yksi esimerkki on Sun Web Developer Pack. Lisätietoa löytyy myös GlassFish-projektin sivuilta. Myös mm. Google ja NetBeans tarjoavat tutustumisen arvoisia työkaluja. WADLiin kannattaa kuten muihinkin standardeihin tutustua myös esimerkkien avulla. Myös esim. Joe Gregorion blogi-kirjoitukset ovat mielenkiintoista luettavaa. Hieman kriittisemmän näkökulman hän esittää esimerkiksi haastattelussa Do we need WADL? (http://bitworking.org/news/193/do-we-need-wadl). Muita aktiivisia ja asiantuntevia ReST/WADL aiheista kirjoittavia ovat mm. Mark Baker, Benjamin Carlyle, Duncan Cragg, Mark Nottingham, Sam Ruby ja Stefan Tilkov. 221