API

En av de viktigste formålene med et API er at ulike datasystemer kan nyttiggjøre seg av hverandres funksjonalitet. Istedenfor å bygge alt fra bunnen av kan utviklere hente data og tjenester fra andre systemer og bygge videre på dem. For eksempel kan en nettbutikk benytte seg av Vipps som betalingsløsning, istedenfor å utvikle sin egen, og skal du lage en mobilapp som trenger værdata, kan du benytte deg 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, alt fra operativsystemer til store språkmodeller og andre former for kunstig intelligens. Ikke bare mellom ulike virksomheter, men også mellom komponenter og tjenester internt i samme system, som for eksempel systemer basert på mikrotjenestearkitektur.

Å kunne integrere og programmere mot API-er er derfor en sentral kompetanse innen de fleste typer programvareutvikling.

Når vi bruker en nettbank, har vi som bankkunder ikke tilgang til hele banksystemet. Vi kan f.eks. ikke selv justere renten eller ta ut penger fra andres kontoer. Vår aktivitet er begrenset til utvalgte transaksjoner og operasjoner på våre egne kontoer. 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 andre ord fungere som en sikkerhetskontroll, der autentisering og tilgangsregler avgjør hvem som får tilgang til ulike data og tjenester. Dermed kan systemet beskyttes mot uønsket bruk og manipulering.

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

Kommunikasjonen mellom dataprogrammene følger det såkalte klient/tjener-prinsippet, også kjent som klient-server-arkitektur. Klienten sender forespørsler til tjeneren (eng. 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. Servitøren formidler bestillingen til kjøkkenet, og når maten er klar, serveres den til gjesten. I denne analogien tilsvarer gjesten klienten og kjøkkenet tjeneren. Menyen kan sammenlignes med API-et, fordi den beskriver hvilke tjenester som er tilgjengelige og hvordan de kan bestilles. 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 for å håndtere.

Etter hvert som flere og flere datasystemer kommuniserer med hverandre, baserer mange leverandører seg på standardiserte måter å lage API-er. Dette gir forutsigbar kommunikasjon, effektiv datautveksling og god verktøystøtte på tvers av plattformer.

• REST (Representational State Transfer) er den vanligste arkitekturstilen for HTTP-baserte API-er. Den bruker nettadresser (URL-er), følger klient/tjener-prinsippet, 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 forespørsel. Dermed unngås unødig datatrafikk. Det er mye brukt i mobilapplikasjoner (apper), men også av webapplikasjoner.
• gRPC er et RPC-rammeverk (Remote Procedure Call). Det er mye brukt «bak kulissene» mellom mikrotjenester fordi det er effektivt, krever lite båndbredde og brukes sjeldent direkte fra nettleseren.

Synkrone API-er fungerer som en høflig samtale mellom to parter, der ingen prater i munnen på hverandre. Klienten sender en forespørsel til tjeneren via API-et og venter så mens denne behandles. Først når svaret er mottatt, kan klienten jobbe videre. Denne typen API-er brukes gjerne i forbindelse med enkle oppgaver, som for eksempel innlogging.

Skal mer tidkrevende forespørsler behandles, vil asynkrone API-er være mer effektive. For hver forespørsel får klienten en melding om at forespørselen er mottatt og under behandling, mens svaret gjerne kommer senere. I ventetiden blir ikke klienten blokkert, men kan fortsette arbeidet sitt i påvente av svaret. Denne typen API-er er spesielt egnet for mer kompliserte forespørsler der store datamengder skal overføres, som for eksempel bildeopplastninger og videooverføring.

Det finnes mange API-er som kostnadsfritt gir andre datasystemer tilgang. Spesielt innenfor offentlig virksomhet og åpen kildekode er det vanlig. Andre API-er (freemium-modeller) tilbyr grunnleggende tjenester gratis, men krever betaling for mer avanserte tjenester, som f.eks. sanntidsdata. I tillegg har vi rene kommersielle selskaper som utvikler programvare kun 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, da det forenkler utvikling av ny programvare.

• programmering
• operativsystem