Hvad er et REST-API?
Et REST-API er den mest almindelige måde at bygge API’er til nettet på. Data ses som ressourcer der tilgås via webadresser, og man håndterer dem med standardverberne hent, opret, opdater og slet. REST blev standard fordi det er enkelt, kan caches og er sproguafhængigt: Et hvilket som helst API kan tale med det.
Åbner du et tilbud eller lytter med på et teknisk møde, dukker “REST-API” op igen og igen, ofte som om alle allerede vidste hvad det var. Faktisk er idéen enklere end forkortelsen antyder, og den er værd at forstå: REST er langt den mest almindelige måde at bygge API’er til nettet på, og næsten alle integrationer I møder, vil tale netop det. Her er forklaringen uden unødig teknik.
Ressourcer og verber
Grundidéen i REST er at se data som ressourcer, og en ressource er simpelthen en ting API’et håndterer: en kunde, en ordre, et produkt. Hver ressource får sin egen webadresse, på samme måde som hver side på en hjemmeside har sin adresse.
For at arbejde med ressourcerne bruges et lille, fast antal standardverber, nettets egne: hent, opret, opdater og slet. Kombinationen af en adresse og et verbum siger alt hvad der er brug for. Hent kunden på denne adresse. Opret en ny ordre. Opdater dette produkt. Slet den post dér.
Det fine er at mønstret er så forudsigeligt. Har du forstået hvordan én ressource fungerer, har du i princippet forstået dem alle, for de følger samme logik. Det er en stor del af grunden til at REST føles let at arbejde med.
Et letlæseligt eksempel
Lad os sige at I har et system med kunder. For at hente en bestemt kunde laver appen et kald med verbet “hent” mod kundens adresse, cirka “hent kunde nummer 42”. Serveren svarer med data om netop den kunde, oftest i formatet JSON, som også kan læses af et menneske:
- navn: Anna Hansen
- e-mail: anna@example.dk
- by: København
Vil appen i stedet tilføje en ny kunde, bruger den verbet “opret” mod adressen for kunder og sender de nye oplysninger med. Vil den opdatere en kunde, bruger den “opdater” mod netop den kundes adresse. Det samme enkle mønster hele vejen: en adresse der udpeger hvad, et verbum der siger hvad der skal gøres og et svar i et format som både systemer og mennesker kan læse.
En egenskab der gør REST forudsigeligt, er at hvert kald står på egne ben. Serveren behøver ikke at huske hvad klienten spurgte om sidste gang: Al den information der er brug for, ligger i selve kaldet. Det betyder at kaldene kan håndteres uafhængigt af hinanden, fordeles over flere servere og skaleres op uden besvær. Den samme egenskab er en del af grunden til at REST-svar er lette at gemme og genbruge: Et givet kald mod en given adresse giver et forudsigeligt svar.
Hvorfor REST blev standard
REST er ikke den eneste tænkelige form, men den blev den dominerende. Tre egenskaber forklarer hvorfor.
- Enkelt. Mønstret med ressourcer, adresser og verber er lille og let at lære. Udviklere genkender det med det samme, og det gør API’er hurtigere og billigere både at bygge og at koble sig på.
- Kan caches. REST hviler på nettets egen infrastruktur, og den kan gemme svar for at slippe for at hente det samme igen og igen. Det gør løsninger hurtigere og billigere at drifte uden ekstra arbejde.
- Sproguafhængigt. Et REST-API er ligeglad med hvilket programmeringssprog klienten er bygget i. En app, en webløsning og et andet system kan alle tale med det samme API. Det gør REST til en fællesnævner der binder forskellig teknologi sammen.
Tilsammen gjorde de egenskaber REST til det naturlige standardvalg for nettet. Når noget “bare skal tale med et API”, er det oftest et REST-API der menes.
Alternativerne, kort
Der findes andre måder at bygge API’er på. GraphQL lader klienten spørge efter præcis de felter den vil have i ét enkelt kald, hvilket er nyttigt når mange forskellige klienter har brug for forskellige visninger af de samme data. gRPC er lavet til hurtig kommunikation mellem tjenester internt, mere end mod almindelige apps.
Begge har deres anvendelser, men ingen af dem har fortrængt REST til almindelige web-API’er. Til langt de fleste behov er REST stadig både standardvalget og det der er nok.
Vi hos Weapp bygger REST-API’er og de integrationer der bruger dem, og hjælper med at vurdere hvad et systems API betyder for jeres muligheder. Vil I forstå hvordan jeres systemer kan kobles sammen? Se vores ydelser eller kontakt os.
Ofte stillede spørgsmål
Hvad står REST for?
REST står for Representational State Transfer, men navnet siger mindre end princippet. Det er en stil til at bygge API’er hvor data behandles som ressourcer man når via webadresser og arbejder med gennem nettets egne verber. Du behøver ikke at kunne den fulde term for at forstå idéen: adresser til ting, standardhandlinger til at arbejde med dem.
Hvad menes der med ressourcer og verber i et REST-API?
En ressource er en ting API’et håndterer, f.eks. en kunde eller en ordre, og hver ressource har sin egen webadresse. Verberne er standardhandlingerne: hent, opret, opdater og slet. Kombinationen af en adresse og et verbum siger det hele: hent denne kunde, opret en ny ordre. Det er et lille, forudsigeligt mønster der går igen overalt.
Hvad er forskellen på REST og JSON?
De hænger sammen, men er forskellige ting. REST er måden at strukturere API’et på: ressourcer, adresser og verber. JSON er det format dataene oftest sendes i, en letlæselig måde at skrive information ned på. Et REST-API bruger næsten altid JSON til svarene, men JSON kan også bruges i mange andre sammenhænge. REST er strukturen, JSON er emballagen.
Hvad er alternativerne til REST?
De mest almindelige er GraphQL og gRPC. GraphQL lader klienten spørge efter præcis de felter den vil have i ét kald, hvilket passer når mange forskellige klienter har brug for forskellige datavisninger. gRPC er bygget til hurtig kommunikation mellem tjenester internt. Begge har deres anvendelser, men REST er stadig standardvalget for de fleste web-API’er takket være sin enkelhed.
Har jeg brug for et REST-API til mit produkt?
Næsten altid når produktet har en app eller en webløsning der henter data fra en server. REST er standardmåden at lade den kommunikation foregå på, og det meste I kobler jer på, vil tilbyde et REST-API. I behøver ikke selv at kunne bygge det, men det er godt at vide at det oftest er den form jeres integrationer kommer til at bruge.