Datarajapintojen jälkeen koittaa toiminnallisten-APIen aikakausi

Updated: Jun 15, 2018

Tällä kertaa päätin ottaa käsittelyyn sellaiset rajapinnat kuin datarajapinta, reaaliaika/tapahtumapohjainenrajapinta ja toiminnallinen rajapinta. Kiedon tarinan käytännöllisen, hyvin monen tunteman ja kokeman esimerkin ympärille - liikkuminen.


Edellisessä kirjoituksessa käsittelin APIen lajityyppejä kuten esimerkiksi sisäinen API, kumppani-API, julkinen API ja avoimen datan rajapinta. Toinen tapa lähestyä APIen moninaisuutta on miettiä niiden toimintaa ja mikä niiden palvelulogiikka on. Tämän artikkelin taustatyötä tehdessä oivalsin olevani API- ja alustatalouden antropologi. Tutkin ja selitän digitaalisen maailman ilmiöitä välillä uutta luomalla, mutta pääosin olemassa olevaa selittäen ja luokitellen.


Datan käsittely rajapinnan kautta


Datarajapinnat tarjoavat keinon lukea, muokata ja poistaa tietoa tietojärjestelmästä. Yleisimmin tehdään rajapinta, jonka kautta voi lukea eli hakea tietoa. Nykyisin nämä rajapinnat ovat REST rajapintoja.


Hyvin usein tässä kohdin puhutaan pyyntö-vastaus paradigmalla toimivasta rajapinnasta. Sovellus pyytää jotain rajapinnalta, odottaa ja saa vastauksen (request/response). Joissain tapauksissa kyse on sarjasta pyyntö-vastaus pareja eli rajapintaan tehdään useita kyselyitä, jotta tarvittava tieto saadaan kerättyä. Riippuen yhteyden laadusta ja APIn tehokkuudesta (tai sen taustalla olevan järjestelmän tehokkuudesta) odotus voi olla pitkäkin aika. Mikä sitten on pitkä aika riippuu kontekstista. Julkisen APIn kohdalla useiden sekuntien odottelu on auttamatta liian pitkä aika ottaen huomioon että sama sovellus voi käyttää useita rajapintoja.


Muokattu kuvasta, joka löytyy https://realtimeapi.io/hub/getting-started-realtime/

Esimerkki tämäntyyppisestä rajapinnasta on vaikkapa linja-autojen pysäkkiaikataulut, junien aikataulut, lentojen, ratikoiden ja metrojen aikataulut muutaman mainitakseni. Tällöin sovelluskehittäjä voi rajapintaa kutsumalla hakea tietoa vaikka Tampereen TKL:n linjan 8 aikataulun pysäkeittäin, saa vastauksen odotettuaan jonkin aikaa ja esittää sen sovelluksessa loppuasiakkaalle. Monesti tämän tyyppinen datarajapinta on julkinen API eli sitä voi käyttää ilman sopimuksia tai muita estoja. Kyseessä ei välttämättä ole avoimen datan rajapinta eli sisällön lisenssi voi asettaa ehtoja tietojen käytölle. Lisää rajapintatyypeistä löytyy edellisestä artikkelista “Ohjelmointirajapinnan moninaiset kasvot


Samaa rajapintaa voidaan käyttää myös tietojen muuttamiseen, linjojen lisäämiseen ja poistamiseen. Tällöin rajapinnan hyödyntäjä ei tosin ole kuka tahansa, vaan rajoitettu joukko kehittäjiä, joilla on oikeus käyttäää rajapinnan tarkoitukseen tarjoamia toimintoja. Tämäntyyppisten ominaisuuksien käyttö vaatii yleensä tunnistautumisen ja käyttäjätunnukseen liitettyjä käyttöoikeuksia, joiden hallinnasta vastaa rajapinnan omistaja.


Tapahtumiin pohjautuvat rajapinnat laajentavat API-kenttää


Edellisessä esimerkissä sovelluskehittäjä on aktiivinen rajapinnan kutsuja eli saadakseen linja-auton aikataulun, hän tekee ohjelmallisen kutsun rajapintaan. Aikataulut muuttuvat harvoin tai ainakin jollain syklillä (kesä/talvi aikataulut), eikä ole jatkuvaa tarvetta kysellä aikatauluja uudestaan ja uudestaan. Toki niin voi tehdä, mikään ei sitä estä.


Sama toimintamalli ei ole järkevää esimerkiksi linja-autojen sijainnin selvittämiseksi. Sovelluskehittäjä joutuisi kysymään kaikkien linja-autojen sijaintia rajapinnalta koko ajan voidakseen esittää ne kartalla oikeassa sijainnissa loppukäyttäjälle. APIa hyödyntävä sovellus tekisi ehkä kymmeniä kutsuja sekunnin välein. Tämä puolestaan jo pelkästään kuulostaa tyhmältä ratkaisulta, mutta samalla aiheuttaa tarpeetonta liikennettä tietoverkkoon sekä jossain määrin rasittaa APIa turhaan, vaikka APIssa olisi käytössä tehokas välimuisti. Linja-auton paikan selvittämisessä ja seuraamisessa reaaliaikainen API on hyvä ratkaisu. Kohtalaisen hyvän kattauksen reaaliaikarajapinnoista ja eri mahdollisuuksista löytää Kin Lane'n aiheelle dedikoidusta alidomainista http://realtime.apievangelist.com/


Kun perinteisen pyyntö-vastaus periaatteeseen perustuvan rajapinnan rajat tulevat vastaan, katse kääntyy monesti reaaliaikaisiin tai tapahtuma/herätepohjaisiin (event) rajapintoihin. Kuitenkaan näitä kahta termiä ei saisi sotkea keskenään synonyymeiksi. Tapahtumapohjaisuus ei välttämättä tarkoita reaaliaikaisuutta, vaikka monesti siihen pyritäänkin.


https://twitter.com/janikarh/status/1000973513174474752


Tiivistetysti voidaan todeta heräte/tapahtumapohjaisen olevan enemmän toimintamalli verrattuna esim perinteiseen REST toteutukseen, jossa asiakas (sovellus) on aktiivinen prosessin aloittava osapuoli kuten yllä on kuvattu. Tapahtumapohjaisessa rajapintapalvelussa asiakassovellus on passiivinen ja tietoa “työnnetään” (push) asiakassovellukselle. Reaaliaikarajapintaan verrattuna tapahtumarajapinnasta usein puuttuu kaksisuuntaisuus. Reaaliaikarajapinnat ovat tyypillisesti eri tekniikkaa, kuten esimerkiksi websocket tai MQTT, eivätkä perustu REST malliin. Tapahtumapohjaisen toiminnon toteutus puolestaan voi olla API (toteutustapa vaihtelee), API webhook tai perinteinen webhook.


ProgrammableWeb listaa 1174 reaaliaikarajapintaa, joka on noin 6% kaikista rajapinnoista. Tapahtumapohjaisten APIen listausta ei ole kyseisessä palvelussa ainakaan suoraan.

Tapahtumapohjaisen-APIn toimintalogiikka on verrattavissa sähköpostilistaan, jossa lista ilmoittaa uusista uutisista halutulla intervallilla kaikille, jotka ovat listalle liittyneet. Ratkaisussa sovellus saa tiedon esimerkiksi datassa tapahtuneesta muutoksesta, ilman että sovelluksen pitää jatkuvasti kysyä APIn kautta onko muutoksia, entä nyt, no entäs nyt, olisiko jo? Keskeistä on halutussa asiassa tapahtunut tilan muutos, joka halutaan välittää tehokkaasti sitä tarvitseville. Englanninkielellä käytetään termiä subscription model.


Keskeistä on halutussa asiassa tapahtunut tilan muutos, joka halutaan välittää tehokkaasti sitä tarvitseville ilman että tilaaja sitä kysyy erikseen.

Tapahtumarajapinta voidaan toteuttaa monilla teknologioilla mutta helpointa on olla rakentamatta sitä ja käyttää ratkaisua, jossa APIa hyödyntävä sovellus on tilaaja. Tällöin asiakkaiden ja omien sisäisten rajapintojen väliin tulee välityspalvelin (proxy) kuten kuvassa alla.


Esimerkiksi Slack, Instagram ja Google käyttävät tätä ratkaisua. Yhtenä merkittävänä etuna mallissa on mahdollisuus rakentaa reaaliaika- ja tapahtumarajapinnat olemassa olevien rajapintojen (data ja toiminnalliset) päälle. Toisaalta tapahtumapohjaiseen logiikkaan perustuva rajapinta voi olla myös webhook tekniikalla höystetty perinteinen data-API ilman välityspalvelinta.


Mikä on sitten reaalirajapintojen osuus kaikista rajapinnoista? Tätä on vaikea sanoa, mutta esimerkiksi ProgrammableWeb (Real Time) listaa 1174 reaaliaikarajapintaa, joka on noin 6% kaikista rajapinnoista.


Tekoälyn aikakaudella toiminnalliset rajapinnat realisoituvat


Artikkelin esimerkkiteemassa eli liikkumisessa toiminnalliset rajapinnat löytyvät esimerkiksi reittiohjeina. Käyttäjä haluaa siirtyä julkisilla liikennevälineillä esimerkiksi Tampereella Leinolasta Tohloppiin ja sitä varten pitää saada tarjottua tieto mahdollisista reittivalinnoista, linja-autoista (jatkossa myös ratikka) ja niiden vaihtoajoista/paikoista loppukäyttäjälle.


Muuttuuko data-APIt tarpeettomiksi toiminnallisten- ja reaaliaikarajapintojen aikakaudella? Ei suinkaan, sillä ne edelleen tarjoavat monesti parhaan keinon muuttaa dataa järjestelmissä, ja toiminnalliset sekä reaaliaikarajapinnat välittävät muuttuneen tiedon eteenpäin kehittäjäystävällisesti. Lisäksi tapahtumapohjaisten rajapintojen hyödyntäjiksi liittymistä usein hallitaan perinteisellä REST rajapinnalla. Loppujen lopuksi on kyse siitä, mitä rajapintaa hyödyntävät sovelluskehittäjät tarvitsevat. Ei tapahtumapohjaista tai reaaliaikaista rajapintaa kannata tehdä, jos sille ei ole tilausta.

REST tyyppiset rajapinnat tarjoavat monesti parhaan keinon muuttaa dataa järjestelmissä, ja toiminnalliset sekä reaaliaikarajapinnat välittävät muuttuneen tiedon eteenpäin kehittäjäystävällisesti.

Yksi syy toiminto-APIen yleistymiselle on trendi, jossa dataa kerätään paljon, mutta pääsyä itse raakadataan ei anneta joskus edes asiakkaalle. Suoran pääsyn sijasta tarjotaan toiminnallisia rajapintoja datan päälle, jotka tuottavat lisäarvoa asiakkaille. Usein lisäarvo syntyy algoritmien ja joskus jopa tekoälyn avulla tehdystä analyysista, jonka alkusyötteen asiakas saattaa antaa.


Esimerkkiteemassa toiminnallinen API saa syötteenä kaksi pistettä kartalla (sijaintia) ja niiden perusteella algoritmi muodostaa vaihtoehtoisia reittejä matka-aikoineen, jotka se palauttaa sovellukselle, joka puolestaan näyttää ne loppukäyttäjälle asiakas(ihmis)ystävällisesti.

Yksi esimerkki tämän tyyppisestä toiminnallisesta rajapinnasta on suosittu OpenTripPlanner. Digitransitin ytimenä on OpenTripPlanner, ympärille on tehty UI ja tueksi liitetty muutama muu API.


Kun katsantokantaa laajennetaan julkisen sektorin ulkopuolelle päästään MaaS konseptin pariin. MaaS ratkaisussa useat liikennevälineet on “niputettu” yhteen: junat, linja-autot, taksit ja ratikka. Tyypillisesti toimintamuoto on alustamainen; yksi osapuoli huolehtii alustasta, toimittajat tuottaa osaratkaisuja, sovelluskehittäjät jotka tekevät kuluttajille palveluita. Sen tarkemmin en ole perehtynyt MaaS ratkaisujen sielunelämään, jotta voisin niiden tekoälystä mitään sanoa. Joka tapauksessa on selvää, että toiminnalliset rajapinnat, data ja reaaliaikarajapintojen lisäksi ovat osa nykyaikaisia MaaS palveluita.





Tilaa APItalisti tilaisuuteen puhumaan!


Kokenut puhuja jota isotkaan yleisöt tai yllättävät tilanteet eivät jäädytä.

Katso referenssit ja hinnasto sekä tee tilaus.

265 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ää!