Hopp til hovedinnhold

API. Den svarte boksen

API (Application Programming Interface), REST, CRUD, Integrasjonsløsninger. Disse er alle begreper som er høyst relevant for en programmerer i dag, men hvorfor?

La oss starte med hva et API egentlig er. Direkte oversatt til norsk er ordets betydning applikasjonsprogrammeringsgrensesnitt (på grensen til norges lengste?). Et API lar deg utvikle en egen programvare, eller en komponent til eksisterende programvare som baserer seg på å skrive data til, og hente data ut i fra et annet datasystem, ofte kalt Integrasjonsløsninger. Et eksempel på dette kan være at en applikasjon på din mobiltelefon får data fra din fitbit. Her benytter applikasjonen seg av å snakke med et API som ber om å motta data fra din fitbit-enhet.

The black box

API kan ofte også betegnes som en såkalt «black box». Man gjør en forespørsel mot en black box, enten ved å sende data til den, eller be om data fra den. Den svarte boksen vil deretter behandle din forespørsel, og gi deg et resultat tilbake. Hva som egentlig skjer inni denne boksen vet vi ikke, men vi kan ha en viss idè om hva vi kan forvente å få tilbake fra den igjen, basert på vår forespørsel. Dette avhenger alltid av hvor god programmeringsjobben som er gjort i den svarte boksen er, og hvor godt dens offentlige funksjoner er dokumentert. Slike svarte bokser finner vi som jobber som programmerere stort sett i alt vi jobber med uten å tenke noe spesielt over det. Selv når jeg trykker på knappen «Publiser» etterpå nå for å legge ut denne artikkelen, så vil all denne dataen kjøres gjennom en funksjon som håndterer den før den lagres på en måte som jeg ikke kjenner til, men jeg har en viss formening om hva som vil skje.

Økt etterspørsel

I vår arbeidsdag ser vi en økt forespørsel etter oppdrag som krever akkurat denne typen kommunikasjon med tredjeparts API-løsninger. I fjor utviklet vi en ny nettside for 3T hvor vi laget et grensesnitt som både henter ut data i form av tilgjengelige treningstimer og sender data inn til systemet i form av brukerregistreringer, betalinger etc. Dette lot seg gjøre siden deres administrasjonssystem var utrustet med en API-løsning vi kunne bygge grensesnittet for nett rundt. Og det er akkurat her denne teknologien har begynt å gjøre store fremsteg de siste årene.

Teknologiene er i stadig endring

Tidligere besto nettsider og nettløsninger gjerne av ren kommunikasjon ut mot brukeren, eller kun mellom brukeren og løsningen med enveis kall frem og tilbake mellom de to. Nyere teknologi som Websockets, Node.js etc. har lagt grunnlaget for en helt ny måte å forholde seg til webapplikasjoner og nettløsninger på. Dette legger også andre rammer for oss som skal sitte å utvikle disse løsningene. Der hvor vi før utviklet løsninger som snakket direkte mellom nettleser og database, legger vi i dag opp til REST og CRUD-baserte API’er som skal levere og håndtere data mellom bruker og løsning.

Dette gjør at man får en mer skalerbar løsning, og har full kontroll på all dataflyt. I tillegg gir dette deg muligheten til å videreutvikle løsningen på et helt annet nivå enn hva som ville vært mulig med en statisk løsning. Dersom man velger å utvikle løsningen sin basert på Rest / Crud kan man også gi tilgang til andre tredjeparts utviklere eller applikasjoner til å ta del i den samme dataflyten. Her igjen viser jeg til en kunde vi jobbet med i fjor. Vi utviklet et system for ElitePT som lar bruker mate inn treningsdata i systemet. Ved å legge opp dataflyten i denne løsningen via et API har man muligheten til å senere bygge egne applikasjoner for mobiltelefoner, smartklokker, fitbits etc. som kan koble seg opp mot det samme rammeverket som benyttes til å presentere denne dataen i nettløsningen uten behov for å gjøre ekstra endringer, tilpasninger eller videreutvikling av den opprinnelige løsningen.

Ingen vet hva fremtiden bringer

Det finnes mange mammuter i dataverden. Gamle systemer som har blitt videreutviklet og patchet opptil flere ganger, gjennom flere tiår. Disse kan svært ofte være vanskelig å jobbe med, da man må inn i selve rammeverket for å gjøre selv små endringer. Dette kan fort være både tidkrevende og kostnadsdrivende. Derfor anbefaler jeg å tenke på skalerbarhet fra starten av utviklingen. Du vet kanskje hva du har behov for i dag, men det behovet endrer seg gjerne med tiden. Sørg for at du lager løsninger som både er bærekraftige i dag, og i fremtiden. Ved å velge en datamodell som denne låser du deg heller ikke til en bestemt teknologi for å håndtere data i visning ut mot brukeren. I dag passer kanskje dataene du har best mot PC, neste år passer de kanskje bedre på en klokke, eller et VR-headset(?).

Du er frakoblet.