Hva er et API, egentlig?

Du åpner værappen, og tallene dukker opp med en gang: seks grader, lett skydekke, kanskje regn mot kvelden. Appen har ikke funnet dette ut selv – den har spurt en annen datamaskin, fått et svar formatert akkurat slik den ventet det, og vist deg resultatet. Det den nettopp gjorde, kalles å bruke et API.

Ordet API har svingt mellom to former. Den vanlige i dag er «application programming interface». Den opprinnelige, uten -ing-endelsen, «application program interface», dukket først opp i en artikkel om datagrafikk på avstand, lagt fram på en AFIPS-konferanse i 1968. Betydningen har flyttet seg siden: informatikeren Roy Fielding beskrev i doktoravhandlingen sin fra 2000 et «nettverksbasert API» – i praksis det vi i dag kaller REST-API-er, byggeklossen bak det meste av det som skjer på nettet – som en motsetning til de eldre API-ene, som var bundet til ett bestemt programmeringsbibliotek. Det er den nettverksbaserte varianten folk mener når de sier «API» i dag.

Selve ideen er enklere enn ordet. Et API er en avtalt måte for to dataprogrammer å snakke sammen på. Det ene programmet spør om noe – en værmelding, en betaling, en adresse – på et format det andre programmet forstår, og får svar tilbake på samme format. Ingen av dem trenger å vite hvordan det andre er bygget innvendig. De trenger bare å følge avtalen.

Et konkret eksempel: Meteorologisk institutt driver api.met.no, et vær-API der dataene er fritt tilgjengelig under en Creative Commons-lisens, også til kommersiell bruk. En utvikler som vil bygge en værapp, trenger ikke måle temperaturen selv – hun spør API-et om værmeldingen for et gitt sted, og får et strukturert svar tilbake. Det er den samme typen avtale værappen din bruker hver gang du sjekker den.

Vipps er et annet eksempel, med en annen jobb å gjøre. Selskapet tilbyr utviklere flere API-er: ett for nettbetaling (ePayment API), ett for gjentakende betalinger som abonnement (Recurring API), og ett for innlogging (Login API). En nettbutikk som vil la deg betale med Vipps, kobler seg til ePayment API-et i stedet for å bygge sin egen betalingsløsning fra bunnen. For å gjøre det må butikken først hente API-nøkler fra Vipps' forretningsportal – nøklene bekrefter at forespørselen faktisk kommer fra den butikken den utgir seg for å være. Under utvikling snakker butikken med en testadresse; når løsningen er klar til bruk, byttes den til produksjonsadressen. Selve betalingen skjer aldri i nettbutikkens eget system – den skjer hos Vipps, og butikken får bare beskjed om utfallet.

Det samme prinsippet ligger under mye av det offentlige Norge har bygget. På data.norge.no finnes en API-katalog som samler beskrivelser av grensesnittene til data som virksomheter har gjort tilgjengelig. Alle API-ene som publiseres der, følger én felles standard, DCAT-AP-NO, slik at de kan gjenbrukes på tvers av etater. Det er derfor en ny offentlig digital tjeneste ofte kan hente inn folkeregisterdata eller adresseopplysninger uten å bygge egne kopier av dem – tjenesten spør et API en annen etat allerede har bygget, i stedet for å finne opp hjulet på nytt.

Så neste gang noen sier at en løsning «har et API» eller mangler et, betyr det ganske enkelt dette: finnes det en avtalt dør inn til dataene eller funksjonene her, som andre programmer kan bruke uten å måtte forstå alt som skjer bak den? Har den det, kan andre bygge videre på den. Har den det ikke, må alt bygges fra bunnen hver gang.