Hva er et REST-API?

Åpner du et tilbud eller sitter i et teknisk møte, dukker «REST-API» opp gang på gang, ofte som om alle allerede visste hva det var. I virkeligheten er ideen enklere enn forkortelsen antyder, og den er verdt å forstå: REST er den klart vanligste måten å bygge API-er for nettet på, og nesten alle integrasjoner dere møter, kommer til å snakke nettopp det. Her er forklaringen uten unødvendig teknikk.

Ressurser og verb

Grunnideen i REST er å se på data som ressurser, og en ressurs er rett og slett en ting API-et håndterer: en kunde, en ordre, et produkt. Hver ressurs får sin egen nettadresse, på samme måte som hver underside på en nettside har sin adresse.

For å jobbe med ressursene brukes et lite, fast antall standardverb som er nettets egne: hente, opprette, oppdatere og slette. Kombinasjonen av en adresse og et verb sier alt som trengs. Hent kunden på denne adressen. Opprett en ny ordre. Oppdater dette produktet. Slett den posten der.

Det fine er at mønsteret er så forutsigbart. Har du forstått hvordan én ressurs fungerer, har du i prinsippet forstått alle, for de følger samme logikk. Det er en stor del av grunnen til at REST føles lett å jobbe med.

Et lesbart eksempel

Si at dere har et system med kunder. For å hente en bestemt kunde gjør appen et kall med verbet «hente» mot kundens adresse, omtrent «hent kunde nummer 42». Serveren svarer med data om akkurat den kunden, som oftest i formatet JSON, som er lesbart også for et menneske:

• navn: Kari Nordmann
• e-post: kari@example.no
• by: Oslo

Vil appen i stedet legge til en ny kunde, bruker den verbet «opprette» mot adressen for kunder og sender med de nye opplysningene. Vil den oppdatere en kunde, bruker den «oppdatere» mot akkurat den kundens adresse. Samme enkle mønster hele veien: Adressen peker ut hva, verbet sier hva som skal gjøres, og svaret kommer i et format både systemer og mennesker kan lese.

En egenskap som gjør REST forutsigbart, er at hvert kall står på egne ben. Serveren trenger ikke å huske hva klienten spurte om forrige gang; all informasjonen som trengs, ligger i selve kallet. Det gjør at kallene kan håndteres uavhengig av hverandre, fordeles over flere servere og skaleres opp uten komplikasjoner. Den samme egenskapen er en del av grunnen til at REST-svar er lette å lagre og gjenbruke: Et gitt kall mot en gitt adresse gir et forutsigbart svar.

Hvorfor REST ble standard

REST er ikke den eneste tenkelige formen, men den ble den dominerende. Tre egenskaper forklarer hvorfor.

• Enkelt. Mønsteret med ressurser, adresser og verb er lite og lett å lære. Utviklere kjenner det igjen med en gang, og det gjør API-er raskere og billigere både å bygge og å koble seg til.
• Lett å mellomlagre (cache). REST hviler på nettets egen infrastruktur, og den kan lagre svar for å slippe å hente det samme om og om igjen. Det gjør løsninger raskere og billigere å drifte, uten ekstra arbeid.
• Språkuavhengig. Et REST-API bryr seg ikke om hvilket programmeringsspråk klienten er bygd i. En app, en nettside og et annet system kan alle snakke med det samme API-et. Det gjør REST til en fellesnevner som binder sammen ulik teknologi.

Til sammen gjorde disse egenskapene REST til det naturlige standardvalget for nettet. Når noe «bare skal snakke med et API», er det som oftest et REST-API man mener.

Alternativene, kort

Det finnes andre måter å bygge API-er på. GraphQL lar klienten spørre etter nøyaktig de feltene den vil ha i ett enkelt kall, noe som er nyttig når mange ulike klienter trenger ulike visninger av de samme dataene. gRPC er laget for rask kommunikasjon mellom tjenester internt, mer enn mot vanlige apper.

Begge har sine bruksområder, men ingen av dem har fortrengt REST for vanlige web-API-er. For de aller fleste behov er REST fortsatt både standardvalget og det som holder.

Vi i Weapp bygger REST-API-er og integrasjonene som bruker dem, og hjelper til med å vurdere hva API-et i et system betyr for mulighetene deres. Vil dere forstå hvordan systemene deres kan kobles sammen? Se tjenestene våre eller ta kontakt.