REST API

REST API er en arkitekturstil for programmeringsgrænseflader (API’er), hvor to systemer udveksler data over HTTP ved hjælp af et fast sæt standardiserede metoder som GET, POST, PUT, PATCH og DELETE. Betegnelsen står for Representational State Transfer og beskriver et sæt principper for, hvordan en klient og en server kan kommunikere på en forudsigelig og ensartet måde, snarere end en bestemt teknologi eller et bestemt programmeringssprog.

I praksis betyder det, at en applikation kan hente eller ændre data fra en anden applikation ved at sende en HTTP-forespørgsel til en bestemt adresse (et såkaldt endpoint) og modtage et svar tilbage, typisk formateret som JSON. Når en vejr-app på en telefon viser dagens temperatur, sker det ofte ved, at appen sender et GET-kald til et REST API hos en vejrtjeneste, som svarer med de aktuelle måledata i et struktureret format, appen kan læse og vise videre til brugeren.

Principperne bag REST

Roy Fielding beskrev REST-arkitekturen i sin ph.d.-afhandling i 2000 som en samling af begrænsninger, der tilsammen gør web-baseret kommunikation enkel og skalerbar. De vigtigste principper er:

• Uniform interface: Ressourcer identificeres via faste URI’er, og klienten interagerer med dem på samme måde hver gang, uanset hvilken ressource der er tale om.
• Statsløshed (stateless): Hver forespørgsel indeholder al den information, serveren har brug for. Serveren gemmer ikke information om tidligere kald fra samme klient, hvilket gør det lettere at skalere systemet på tværs af flere servere.
• Cache-egnethed: Svar kan mærkes som cache-bare, så gentagne kald til samme ressource ikke nødvendigvis skal behandles forfra hver gang.
• Klient-server-adskillelse: Klienten (fx en app eller webside) og serveren (der leverer data) kan udvikles og ændres uafhængigt af hinanden, så længe grænsefladen mellem dem holdes stabil.
• Lagdelt system: Der kan indsættes mellemled som lastbalancerer, gateways eller caching-lag mellem klient og server, uden at det ændrer den måde, klienten oplever API’et på.

Sådan foregår et typisk API-kald

Et REST-kald følger som regel et fast mønster: klienten sender en HTTP-forespørgsel til et endpoint, forespørgslen sendes over netværket – ofte over internettet eller et bredere WAN (Wide Area Network), der forbinder systemer på tværs af geografiske afstande – hvorefter serveren validerer og behandler kaldet, eventuelt slår data op i en database, og til sidst returnerer et svar med en statuskode, nogle headers og selve dataindholdet.

De mest anvendte HTTP-metoder har hver deres formål:

• GET henter en eller flere ressourcer, fx en liste af produkter eller én bestemt bruger.
• POST opretter en ny ressource, fx en ny ordre i et e-handelssystem.
• PUT erstatter en hel eksisterende ressource med nyt indhold.
• PATCH opdaterer kun udvalgte felter i en ressource.
• DELETE fjerner en ressource.

Svaret indeholder typisk en statuskode, der fortæller, om kaldet lykkedes (fx 200 for succes eller 201 når noget nyt er oprettet), sammen med data i JSON-format, som klienten kan tolke og bruge videre.

REST API i praksis mellem systemer

REST API’er bruges i dag til stort set al kommunikation mellem uafhængige systemer på nettet: et CMS kan hente eller opdatere indhold via et REST API, en webshop kan trække lagerstatus fra et lagerstyringssystem, og en mobilapp kan tilgå data fra en central server. Fordi svar ofte kan caches, udnyttes REST API’er også sammen med et CDN (Content Delivery Network), så gentagne forespørgsler kan besvares hurtigere tættere på brugeren i stedet for at belaste den oprindelige server hver gang.

Sikkerheden omkring et REST API afhænger typisk af, at trafikken krypteres via HTTPS, og at kaldene kræver en form for godkendelse, fx en API-nøgle eller en adgangstoken. Det adskiller sig fra SSH (Secure Shell), som i stedet bruges til at logge sikkert ind på og administrere en server direkte, snarere end til at udveksle strukturerede data mellem to applikationer.

REST versus SOAP

Før REST blev udbredt, byggede mange systemer på SOAP, som er en strammere protokol baseret på XML med indbyggede krav til sikkerhed og formalitet. REST regnes i mange sammenhænge som det enklere alternativ, fordi det kan arbejde med flere dataformater, som regel er lettere at fejlsøge, og passer godt til webbaserede og mobile applikationer. SOAP bruges stadig i visse virksomhedssystemer, hvor strenge kontrakter og indbygget sikkerhed vejer tungere end enkelhed.

Begrænsninger ved REST

REST er ikke en universel løsning til alle former for systemintegration. Fordi hvert endpoint typisk leverer en fast struktur af data, kan en klient nogle gange ende med at hente mere eller mindre information, end den reelt har brug for. Alternativer som GraphQL er udviklet netop for at lade klienten selv bestemme, hvilke felter der skal returneres, mens REST fortsat er udbredt, fordi det er enkelt at implementere og forstå på tværs af programmeringssprog.