Digitaalisen raaka-aineen liikuttelu sellaisenaan APIn avulla vähenee


Olemme aika tottuneita siihen, että kun puhutaan ohjelmointirajapinnoista (API), niin oletusarvoisesti nähdään ne dataa suoltavina tuutteina. API on väline hakea tietoa ja vastaus monesti on koneluettavassa muodossa olevaa digitaalista raaka-ainetta. Raaka-aine on suodattamatonta ja vaatii käsittelyä ennen kuin sitä voidaan käyttää hyödyksi. Jalostus, analyysi ja tilastojen laskeminen jää dataa pyytävän sovelluksen koodin vastuulle.


REST API on väline hakea tietoa ja vastaus monesti on koneluettavassa muodossa olevaa digitaalista raaka-ainetta.



REST - pakkosyöttöä


REST tyyppinen ajattelu on suosituin. SOAP on elossa, mutta käyttäjäkunta vain vähenee entisestään. REST rajapinta palauttaa datan oman tietomallinsa mukaisesti (sisältö ja tietoelementtin järjestys). Datan pyytäjä ei voi vaikuttaa siihen, että voisi saada paluuarvona vain tarvitsemansa. Sen sijaan tulee pahimmillaan läjäpäin kaikkea mahdollista, jolla ei ole mitään lisärvoa pyytäjälle. Tämä rasittaa verkkoa jossain määrin ja tuntuu muuten vain lievästi hölmöltä tavalta liikuttaa tietoa.


Vähän sama kuin että kysyisin farkkukaupan myyjältä tiettyjen housujen hintaa ja vastauksena saisin hinnan lisäksi pesuohjeet, hinnat kymmenessä eri valuutassa, mitä materiaalia housuissa on käytetty ja värivaihtoehdot. Kyseiset tiedot ovat hyödyllisiä ehkä toisissa tapauksissa, mutta ei juuri minulle ja juuri nyt. Toki tätä ylimääräisen datan pakkosyöttöä voidaan rajoittaa esimerkiksi parametreilla, mutta se on omiaan lisäämään APIn monimutkaisuutta.


Perinteinen request - response joka on normaalia REST rajapinnoissa, on jo murroksessa. Nyt ollaan siirtymässä toiminnallisiin rajapintoihin ja myös siinä on kyse tarpeettoman datan liikuttelun vähentämisestä.


GraphQL - sitä mitä haluan


Viime vuodet GraphQL on tehnyt tuloaan. GraphQL on askel poispäin raakadatamallista. Askel, vaikkei kovin suuri kuitenkaan. GraphQL:ssa kysyjä määrittää mitä tietoja haluaa ja missä järjestyksessä. Ylimääräisen datan pakkosyöttö vähentyy huomattavasti. Toisaalta on myös sanottava, että saman mitä GraphQL tekee, saa aikaan myös REST työkaluilla. GraphQL ei ole “must have” juttu kaikille eikä kaikkiin tilanteisiin.


Yksi suosittu tapa havainnollistaa REST ja GraphQL eroa on hampurilaisen tilaaminen. Alla oleva on toimiva viestinnällisesti vaikkakin GraphQL:sta jotain tietävät ymmärtävät että esimerkki ei toimisi oikeasti.


Edge data processing (IoT)


Tilanne muuttuu merkittävästi kun kyseessä on suuret datamassat ja heikohkojen verkkoyhteyksien päässä olevat dataa keräävät laitteet. Englanninkielessä on termi “edge data processing” enkä nyt äkkiseltään tiedä miten sen hyvin suomeksi kääntäisi. Siinä ajatuksena kumminkin on että dataa kerätään lokaalisti eikä sitä kaikkea sillä samalla hetkellä aina pusketa APIa pitkin pilveen tai keskitettyyn tietovarantoon.


Sen sijaan laite tai laitteiden lokaali verkosto säilöö ja analysoi dataa. Vain tietyin väliajoin tai kun tarve ilmenee, tehdään datasiirto ulos lokaalista verkosta. Tämä on erittäin fiksua ja joskus pakotettu tilanne IoT -maailman laitteissa. Vastaavasti kerättyä dataa käyttävä sovellus ei siis kyselekään tai vastaanota jokaiselta IoT -sensorilta dataa koko ajan, vaan saa analysoidun tuloksen.


Dataliiketoiminta


Tämä näkyy myös tavallisessa “dataliiketoiminnassa”. Esimerkiksi paperitehtaan toimittava yritys saattaa säilöä paperitehtaan paperin ohella tuottaman datan (ja tätä on paljon) pilvipalveluun. Tätä dataa ei suinkaan anneta sellaisenaan paperitehtaan omistajalle, vaan siitä jalostetaan heidän tarpeisiin paremmin sopivaa tietoa, jota sitten tarjoillaan APIn kautta. Raaka-aineeseen ei päästetä, vaan sen sijaan tarjotaan jalostetta. Tässä kohdin voi tietysti nähdä syiksi paperitehtaan toimittavan osapuolen intressin pitää kiinni datasta.


Toisaalta paperitehtaan omistaja ei sitä raaka-aineen muodossa olevaa dataa pysty omissa prosesseissaan käyttämään. Heillä ei ole tarvetta kaikelle tiedolle, joka sensorin lukuarvoille sekunnin tarkkuudella. Näin ollen osana kokonaisvaltaisempaa toimitusta, paperitehtaan valmistaja tuottaa myös raakadatan prosessoinnin. Toki tässäkin voisi tehdä samoin kuin “IoT” esimerkissä, mutta liiketoimintasyyt voivat pakottaa valitsemaan toisen vaihtoehdon.


Ymmärrä APIn asiakasta - lisäarvo halutaan helposti ja nopeasti


Olennaista on ymmärtää, että aikakausi jolloin REST APIn tarjoaminen raakadataan ei enää riitä. Se itsessään ei tuota tarpeeksi nopeasti kenellekään lisäarvoa. Tekee sitten REST tai GraphQL APIa, on aina syytä olla syy miksi se tehdään, kenelle se tehdään ja minkä ongelman se ratkaisee.


Pääset pikakurssille tässä asiassa kuuntelemalla "Opi tuntemaan API -asiakkaasi" podcast -sarjaa.



34 views

©2018 by apitalisti
 

Yhteystiedot

Brändit

Apitalist is registered trademark of APInf Ltd

APIOps is registered trademark of Osaango Ltd and APInf Ltd

Tilaa kirja

API -talous 101 -kirja Alma Talent kaupassa!

Podcast

"Opi tuntemaan API -asiakkaasi" podcast -sarja

Lue lisää!