API

Direkte oversatt til norsk blir Application Programming Interface (API) til applikasjonsprogrammeringsgrensesnitt. Ordet er sammensatt av tre begreper: applikasjon, programmering og grensesnitt.

Et brukergrensesnitt gjør det mulig for en bruker (en person) å samhandle med et dataprogram. Brukergrensesnitt består gjerne av ulike komponenter som tekstfelt, knapper og menyer. Et API er et grensesnitt der den menneskelige brukeren er erstattet av et annet dataprogram. Interaksjonen foregår med andre ord mellom to dataprogrammer, der det ene programmet kan benytte tjenestene som det andre programmet tilbyr.

Et av de viktigste formålene med API-er er at ulike datasystemer kan bruke hverandres funksjonalitet, uten å kjenne til hvordan tjenestene er implementert. Dette skillet mellom grensesnitt og implementasjon gjør det mulig å oppdatere tjenestene, uten at det får negative konsekvenser for eventuelle andre programmer som bruker dem.

Utviklere kan gjennom API-er hente data og tjenester fra andre systemer og bygge videre på dem. En nettbutikk kan for eksempel benytte seg av Vipps som betalingsløsning i stedte for å utvikle sin egen betalingsløsning fra bunnen av. Hvis man skal lage en app som trenger værdata, kan man benytte seg av API-et til Meteorologisk institutt. Dette gir både økt effektivitet, lavere utviklingskostnader og redusert risiko for feil.

Utveksling av data og tjenester via API-er er svært utbredt i så godt som alle typer programvare, fra operativsystemer til store språkmodeller og andre former for kunstig intelligens. Også mellom komponenter og tjenester internt i samme system kan API-er brukes, for eksempel i systemer der mange små programmer samarbeider med hverandre (mikrotjenestearkitektur). Å kunne programmere mot et API er derfor en sentral kompetanse innen de fleste typer programvareutvikling.

Vanlige brukere av en nettbank har ikke tilgang til hele banksystemet. Man kan for eksempel ikke selv justere renten eller ta ut penger fra andres bankkontoer. Aktiviteten til en vanlig bruker er begrenset til utvalgte transaksjoner og operasjoner. På samme måte som en bankkunde bare har tilgang til et begrenset utvalg funksjoner i nettbanken, gir et API vanligvis bare tilgang til utvalgte data og tjenester i et datasystem. API-et kan med andre ord fungere som en sikkerhetskontroll, der autentisering og tilgangsregler avgjør hvem som får tilgang til ulike data og tjenester. På denne måten kan systemet beskyttes mot uønsket bruk og manipulering.

Når mennesker kommuniserer seg imellom, kan man gjerne formulere det samme budskapet på ulike måter og likevel bli forstått. I kommunikasjon mellom dataprogrammer er det annerledes. Der må kommunikasjonen følge strenge og entydige regler slik at det ikke er rom for ulike tolkninger. API-dokumentasjonen beskriver disse reglene, blant annet hvilke forespørsler som er tillatt, hvordan de skal utformes, i hvilket format svaret kan gis, hva de ulike statuskodene betyr og eventuelle begrensninger i bruken av API-et.

Synkrone API-er fungerer som en høflig samtale mellom to parter, der ingen prater i munnen på hverandre. Et dataprogram som sender en forespørsel til et annet via et synkront API må vente mens forespørselen behandles. Først når svaret er mottatt, kan dataprogrammet jobbe videre. Denne typen API brukes gjerne i forbindelse med enkle oppgaver, som for eksempel innlogging.

Når mer tidkrevende forespørsler skal behandles, vil asynkrone API-er være mer effektive. For hver forespørsel får dataprogrammet som sendte den en melding om at forespørselen er mottatt og under behandling, mens svaret gjerne kommer senere. I ventetiden mellom forespørsel og svar kan dataprogrammet fortsette arbeidet sitt uten å bli blokkert. Denne typen API-er er spesielt egnet for mer kompliserte forespørsler der store datamengder skal overføres, som for eksempel opplasting av bilder og overføring av video.

Det finnes mange API-er som kostnadsfritt gir andre datasystemer tilgang. Spesielt innenfor offentlig virksomhet og åpen kildekode er dette vanlig.

Andre typer er freemium-API-er. Disse tilbyr grunnleggende tjenester gratis, men krever betaling for mer avanserte, som for eksempel sanntidsdata.

I tillegg finnes rene kommersielle selskaper som utvikler programvare som kun er rettet mot andre datasystemer, der de tilbyr sine data og tjenester via API-ene. Spesielt innen finans er dette vanlig. Markedet for denne typen API-er er stort, siden det forenkler utvikling av ny programvare.

Etter hvert som flere og flere datasystemer kommuniserer med hverandre, baserer mange leverandører seg på standardiserte måter å lage API-er på.

Slike standarder gir forutsigbar kommunikasjon, effektiv datautveksling og god verktøystøtte på tvers av ulike plattformer.

• REST (Representational State Transfer) er den vanligste arkitekturstilen for HTTP-baserte API-er. Den bruker nettadresser (URL-er) og tilbyr enkle handlinger som å hente, lage, endre og slette data.
• JSON (JavaScript Object Notation) er et enkelt strukturert tekstformat for lagring og utveksling av data.
• SOAP (Simple Object Access Protocol) er en eldre, mer formell protokoll som bruker XML. Den brukes fortsatt i banker og andre bedrifts- og finanssystemer, der sikkerhet og kontroll er avgjørende.
• GraphQL (Graph Query Language) er et spørrespråk og et kjøremiljø for API-er der klienten kan be om akkurat de dataene den trenger i én enkelt forespørsel. Dermed unngås unødig datatrafikk. Det er mye brukt i mobilapplikasjoner (apper), men også av webapplikasjoner.
• gRPCer et RPC-rammeverk (Remote Procedure Call). Fordi det er effektivt og krever lite båndbredde, er det mye brukt «bak kulissene» innenfor systemer der mange små programmer samarbeider med hverandre (mikrotjenestearkitektur).

Kommunikasjonen mellom dataprogrammer følger gjerne det såkalte klient/tjener-prinsippet, også kjent som klient-server-arkitektur. Klienten sender forespørsler til tjeneren (engelsk server) gjennom API-et som tjeneren tilbyr.

Samhandlingen kan sammenlignes med et restaurantbesøk. Gjesten bestiller mat ved hjelp av restaurantens meny og servitør. Hvis rettene står på menyen, formidles bestillingen til kjøkkenet, og når maten er klar, serveres den til gjesten. I denne analogien tilsvarer gjesten klienten og kjøkkenet er tjeneren. Menyen kan sammenlignes med API-et, fordi et API beskriver hvilke tjenester som er tilgjengelige og hvordan de kan aktiveres. På samme måte som gjesten bare kan bestille retter som står på menyen, kan klienten bare sende forespørsler som API-et er utformet til å håndtere.

• programmering
• operativsystem