REST (Representational State Transfer) – definition, principper og eksempler

Få en klar definition af REST, dets principper og konkrete eksempler — guide til RESTful-arkitektur, design og praktiske anvendelser.

REST (Representational State Transfer) er en arkitektonisk stil inden for programmering, der har til formål at øge effektiviteten og enkeltheden i kommunikationen mellem systemer. Idéen er at behandle hver enhed af data som en ressource med en entydig identifikator (typisk en URI). I stedet for at sende komplette kopier af store datamængder mellem parter, deler man referencer (links) til disse ressourcer og henter kun den repræsentation (fx JSON eller XML), man har brug for, når det er nødvendigt. Systemer, der følger disse principper, kaldes ofte "RESTful".

Grundlæggende principper og begrænsninger

• Klient-server: Klient og server er adskilte — klienten håndterer brugergrænsefladen, serveren håndterer data og forretningslogik.
• Stateless (ingen sessionsstatus på serveren): Hver forespørgsel skal indeholde al den information, serveren behøver for at forstå og behandle den. Serveren gemmer ikke klientens tilstand mellem opkald.
• Cacheability: Svar fra serveren bør erklæres som cachebare eller ikke-cachebare for at forbedre ydeevne og reducere belastning.
• Uniform interface: En fælles, veldefineret grænseflade (fx brug af standard HTTP-metoder GET/POST/PUT/DELETE) gør systemer mere forståelige og interoperable.
• Layered system: Arkitekturen kan bestå af flere lag (fx gateway, load balancer, cache) uden at klienten behøver at kende hele stakken.
• Kodbar interaktion (optionel): Hypermedia som applikationens tilstandstransition (HATEOAS) kan gøre services selvbeskrivende ved at inkludere links til relaterede handlinger i svarene.

Hvordan det virker i praksis

I stedet for at kopiere hele et datasæt, adresserer man konkrete ressourcer via deres URI. En klient kan f.eks. bruge GET til at hente en repræsentation af en ressource, POST til at oprette, PUT til at opdatere og DELETE til at fjerne. Repræsentationen kan være i form af JSON, XML, HTML eller andre formater afhængigt af behovet.

Analogier og eksempler

Et praktisk eksempel på et ikke-RESTful system i den virkelige verden er den traditionelle samling af film i hjemmet. For at få adgang til en given film skal ejeren af biblioteket skaffe sig en fysisk kopi af den. Dette medfører et betydeligt spild, da der findes flere kopier, end der er i brug på et givet tidspunkt. Desuden er den tid, der er nødvendig for at tilføje nye titler til biblioteket, generelt ikke triviel. Streaming video er REST-modstykket til hjemmebiblioteket: i stedet for at have en komplet kopi af alle film gemt lokalt, henvises der til filmen ved dens titel, og indholdet streames efter behov.

World Wide Web er det største praktiske eksempel på et RESTful-system i dag. Fysiske biblioteker er dets ikke-RESTful-ækvivalent. I stedet for at sende en fysisk elektronisk kopi af hver digital ressource til hver enkelt person eller bibliotek tildeler vi hver ressource en URL-identifikator "http://example.com", hvorefter vi får adgang til det faktiske indhold via internettet i stedet for at hente en lokal kopi fra en optisk disk eller en harddisk.

REST-arkitekturen kan også anvendes i andre sammenhænge. Tænk f.eks. på to virksomheder, som ønsker at dele flere gigabyte information, der konstant ændrer sig. At sende en komplet kopi af deres databaser til hinanden med jævne mellemrum er ineffektivt og risikabelt. I stedet kan de dele adgang til ressourcer via entydige identifikatorer og hente netop de data, de har brug for, når behovet opstår — det reducerer både netværkstrafik og datadublikation.

Fordele og ulemper

• Fordele: Skalerbarhed, enkelhed, løsrivelse mellem klient og server, mulighed for caching, bred understøttelse (fx via HTTP) og god egnethed til distribuerede systemer.
• Ulemper: Kan være mindre effektiv ved meget komplekse transaktioner der kræver flere round trips; korrekt design af URI'er, statuskoder og cacheregler kræver omhu; HATEOAS implementeres sjældent i praksis.

Praktiske designråd

• Brug meningsfulde, entydige URI'er for ressourcer (fx /orders/123).
• Anvend passende HTTP-metoder og statuskoder (200, 201, 204, 400, 404, 500 osv.).
• Tilbyd konsistente repræsentationer (typisk JSON for moderne web-API'er) og dokumentér felter og fejlformat.
• Benyt caching hvor muligt for at reducere belastningen og forbedre svartider.
• Tænk over sikkerhed: autentificering, autorisation og kryptering (fx HTTPS, OAuth).

Sammenfattende er REST en enkel og kraftfuld arkitekturstil, der har formet, hvordan mange moderne webtjenester designes og bruges. Ved at fokusere på ressourcer, enkle grænseflader og stateless interaktion kan RESTful-systemer være både effektive og lette at vedligeholde.

Spørgsmål og svar

Q: Hvad er Representational State Transfer (REST)?

Q: Hvad kaldes systemer, der implementerer REST?

Spørgsmål: Hvordan kommunikerer computersystemer med hinanden ved hjælp af REST?

Spørgsmål: Hvad dokumenterer REST?

Spørgsmål: Hvem skabte softwarearkitekturstilen Representational State Transfer (REST)?

Spørgsmål: Hvilken type kommunikation anvender REST?

Sp: Hvad er formålet med Representational State Transfer (REST)?

Søg efter bogstav