HATEOAS – paluu kevyempään web-kehitykseen

Ovatko raskaat JavaScript-frontendit ja jatkuva API-versiointi tulleet tiensä päähän? Tietotekniikkaopiskelija Jere Lantz esittelee HATEOAS-arkkitehtuurin, joka palauttaa web-kehityksen juurilleen ja voi pienentää koodikannan kokoa jopa yli 60 prosenttia.

TEKSTI | Jere Lanz, Anna-Kaisa Saari & Tommi Rintala
Artikkelin pysyvä osoite http://urn.fi/URN:NBN:fi-fe20260916126119
Vertailukuva, jossa perinteisen JavaScript-frontendin monimutkaisuus esitetään sekavana palapelinä ja HTMX/HATEOAS-arkkitehtuuri puhtaana, yksinkertaisena koodirakenteena.

Mikä on HATEOAS?

HATEOAS on lyhenne englannin kielen sanoista “Hypermedia As The Engine Of Application State”. Yksinkertaistettuna se tarkoittaa, että sovelluksen tilaa ylläpidetään käyttäen hypermediaa, kuten HTML:ää, tai XML:ää.

HATEOASin tarkoituksena on sisällyttää jokaiseen palvelimen ja asiakkaan väliseen viestiin kaikki tarvittava tieto ilman tarvetta siirtää ylimääräistä dataa muita reittejä. Nykyään, kun frontend rakennetaan esimerkiksi raskaalla JavaScript-kehyksellä, koodi joudutaan siirtämään asiakkaalle täysin erillisenä tiedostona varsinaisesta datakommunikaatiosta.

Yksinkertainen esimerkki HATEOASista

Otetaan esimerkiksi verkkosivu, jossa on painike, joka hakee tietoa backendiltä ja rakentaa tiedoista taulukon.

Nykyään on normaalia, että tämä kutsu tehdään JavaScriptillä ja odotetaan että backend vastaa pelkällä datalla JSON-muodossa. Frontendin JavaScript käsittelee tämän datan ja generoi lopuksi taulukon selaimen näytölle.

Käyttämällä HATEOAS-periaatetta emme juurikaan tarvitse logiikkaa frontend-koodissa. Sen sijaan backend rakentaa HTML-taulukon valmiiksi ja lähettää sen suoraan vastauksena kutsuun. Asiakasohjelma (selain) vain piirtää saamansa valmiin palikan paikalleen.

Työkalut moderniin käyttöön: HTMX ja Hyperview

HTML-standardi tukee tällä hetkellä dynaamisten kutsujen tekemistä varsin rajallisesti. Käytettävissä on kirjastoa, jotka tuovat HATEOAS-toiminnallisuuden moderneihin sovelluksiin helppokäyttöisessä muodossa:

  • HTMX (htmx.org): JavaScript-kirjasto, joka mahdollistaa dynaamisten verkkosivujen tekemisen luomalla uusia HTML-attribuutteja, jotka kutsuvat alla olevaa JavaScript-koodia huomaamattomasti
  • Hyperview (hyperview.org): Kirjasto, joka käyttää omaa HXML-merkintäkieltään. Tämä kirjasto on tarkoitettu erityisesti mobiilisovellusten tekemiseen hypermedia-arkkitehtuurilla.

Jos käytämme esimerkiksi HTMX-kirjastoa, voimme lisätä aiemmin mainittuun haku-painikkeeseen yksinkertaiset hx-get-, hx-target- ja hx-swap-attribuutit. Näillä määritämme:

  • Hx-get = http viestin verbi. Hx-get nimensä mukaan lähettää GET viestin.
  • Hx-target = CSS-valitsin, joka määrittää, minne viestin vastaus (eli valmis HTML-taulukko) laitetaan sivulla.
  • Hx-swap = Miten vaihto tapahtuu (esim. outerHTML korvaa koko vanhan elementin, kun taas innerHTML laittaa vastauksen elementin sisälle).

REST-arkkitehtuurin unohdetut juuret

Huvittava fakta HATEOASista on se, että se oli alun perin yksi tärkeimmistä perusperiaatteista REST-rajapinnan (Representational State Transfer) tekemiseen. Tänä päivänä useimpien ”REST-APIen” toiminta on kuitenkin kääntynyt täysin päinvastaiseksi alkuperäiseen määritelmäänsä nähden, palvellen JSON-dataa HTML:n sijaan.

REST terminä sai alkunsa Roy Fieldingin tohtorinväitöskirjassa vuonna 2000. Myöhemmin, vuonna 2008, Fielding korosti erillisessä artikkelissaan, että aitojen REST API -rajapintojen tulisi käyttää nimenomaan hypertekstiä (Fielding, 2000; Fielding, 2008).

Carson Gross, edellä mainitun HTMX-kirjaston ylläpitäjä, on kirjoittanut aiheesta esseen, jossa hän käy syvällisesti läpi RESTin historiaa ja sitä, miten olemme päätyneet nykypäivän tilanteeseen (Gross, 2022).

HATEOASin suurimmat hyödyt

Miksi tähän vanhaan malliin pitäisi palata?

Ensimmäiseksi, API-rajapintaa ei tarvitse versioida. HATEOAS-rajapintoja ei tarvitse versioida samalla tavalla kuin perinteisiä JSON API -rajapintoja. HATEOAS takaa, että jokainen palvelimen vastaus sisältää valmiina kaiken tarvittavan tiedon ja rakenteen. Ei ole tarvetta olla huolissaan, onko jollain asiakkaalla vanhentunut versio frontend-koodista – koska erillistä frontend-logiikkaa ei juuri ole.

Toiseksi koodin radikaali vähentyminen HATEOASia käyttämällä koodikanta pienenee merkittävästi. Backend-koodi luultavasti pysyy suurin piirtein samana tai kasvaa hieman, mutta erillisen JavaScript-frontendin tarve katoaa.

Tästä on todellisia esimerkkejä, joissa yritykset ovat vaihtaneet raskaat React-frontendit kevyeen HTMX:ään:

  • Guillot (2022) piti DjangoCon 2022 -tapahtumassa esityksen siitä, kuinka heidän SaaS-yrityksensä vähensi koodikannan kokoa uskomattomat 67 %.
  • McPhee (2023) kertoi LinkedIn-julkaisussaan, kuinka heidän ohjelmistonsa koodikannan koko väheni noin 60 % vaihdoksen myötä.

Milloin HATEOAS ei ole oikea ratkaisu

HATEOASilla on monia hyviä puolia, mutta ”hopealuotia” ei ohjelmistokehityksessä ole.

HATEOAS ei todennäköisesti ole paras ratkaisu, jos käyttöliittymä on erittäin monimutkainen ja yksittäisen toiminnon tulee päivittää käyttöliittymää monessa eri paikassa samanaikaisesti. HATEOAS suosii käyttöliittymiä, joissa toiminnallisuus on selkeästi rajattavissa tietylle alueelle. Huonoja käyttökohteita olisivat esimerkiksi Excelin verkkoversio tai Googlen karttapalvelut.

Toinen huono käyttökohde on liikenteen määrä. Jos sovellus on sellainen, että se joutuu siirtämään tai synkronoimaan tietoa jatkuvasti mikrosekuntien viiveellä (esimerkiksi reaaliaikaiset moninpelit), ei jatkuvan HTML:n siirtäminen HATEOAS-mallilla ole järkevää.

Yhteenveto – uusi hype, teollisuuden realiteetit

HTMX ja HATEOAS-arkkitehtuuri tarjoavat raikkaan (joskin historiallisen) tuulahduksen nykyiseen frontend-kehitykseen. Koodikannan koon radikaali pieneneminen ja yksinkertaistunut arkkitehtuuri ovat valtavia houkuttimia. Opiskelijoina ja koodareina on tärkeää kokeilla rohkeasti uutta ja haastaa vallitsevia, usein turhankin monimutkaisia, työtapoja.

Samalla on kuitenkin muistettava teollisuuden realiteetit. Ohjelmistojen elinkaaret mitataan usein vuosikymmenissä, ja miljoonien rivien React- tai Angular-koodikantojen uudelleenkirjoittaminen HTMX:llä vain ”trendikkyyden” vuoksi ei ole suurille yrityksille taloudellisesti tai riskienhallinnan kannalta mahdollista. HATEOAS on erinomainen työkalu oikeassa paikassa, erityisesti uusia, kevyempiä projekteja aloitettaessa, mutta se ei korvaa koko alan nykyistä infrastruktuuria yhdessä yössä.

Lisää tietoa HATEOASista

Carson Gross joka on yksi HTMX-kirjaston ylläpitäjistä, on kirjoittanut monia hyviä blogikirjoituksia HATEOASin käytöstä, sekä sen hyvistä ja huonoista puolista, jotka löytyvät osoitteesta https://htmx.org/essays/.

HTMX-kirjaston ylläpitäjät ovat kirjoittaneet myös kirjan, jossa ensimmäisessä osassa askel kerrallaan muutetaan klassinen Web 1.0 -verkkosovellus, modernimmaksi käyttämällä HTMX-kirjastoa. Toisessa osassa rakennetaan mobiilisovellus Hyperview-kirjastoa käyttäen. Kirja löytyy osoitteesta https://hypermedia.systems/.

Lähteet
  • Fielding, R. T. (2000). Architectural styles and the design of network-based software architectures (Doctoral dissertation, University of California, Irvine). https://roy.gbiv.com/pubs/dissertation/fielding_dissertation.pdf

  • Fielding, R. T. (2008). REST APIs must be hypertext-driven. https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

  • Gross, C. (2022). How did REST come to mean the opposite of REST? https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/

  • Guillot, D. (2022). DjangoCon 2022 | From React to htmx on a real-world SaaS product: we did it, and it's awesome! [Video]. YouTube. https://www.youtube.com/watch?v=3GObi93tjZI

  • McPhee, A. (2023). Post about reducing codebase size with HTMX [LinkedIn post]. LinkedIn. https://www.linkedin.com/feed/update/urn:li:activity:7109116330770878464/

Aiheeseen liittyvää