← Tilbage til DataLex.dk
API

REST API

Forstå hvad en REST API er, hvordan den fungerer, og hvordan du designer og bruger RESTful API'er i praksis.

Hvad er en API?

API (Application Programming Interface) er en grænseflade der lader to programmer kommunikere med hinanden. Tænk på det som en kontrakt: den ene side sender en forespørgsel i et bestemt format, og den anden side svarer med data i et aftalt format.

Når du tjekker vejret på din telefon, sender appen en API-forespørgsel til en vejrtjeneste. Når en webshop viser fragtpriser, kalder den et API hos fragtselskabet. API'er er limet der holder moderne software sammen.

REST (Representational State Transfer) er den mest udbredte arkitekturstil for web-API'er. REST bygger på HTTP-protokollen – den samme som din browser bruger – og bruger standard HTTP-metoder til at udføre operationer på data.

REST-principperne

REST er ikke en protokol men et sæt arkitekturprincipper defineret af Roy Fielding i 2000. En API der følger disse principper kaldes RESTful:

Klient-server

Klient og server er uafhængige. Serveren kender ikke klienten, og klienten kender kun API-endpointet.

Stateless

Hver forespørgsel indeholder al nødvendig information. Serveren husker ikke tidligere forespørgsler.

Cacheable

Svar skal markeres som cachebare eller ej. Caching reducerer belastningen og forbedrer svartider.

Uniform interface

Ressourcer identificeres med URL'er. Operationer udføres med standard HTTP-metoder (GET, POST, PUT, DELETE).

Layered system

Klienten ved ikke om den snakker med serveren direkte eller en proxy. Load balancers og caching-lag er usynlige.

Ressource-baseret

Alt er ressourcer (brugere, produkter, ordrer) der tilgås via URL'er som /api/users eller /api/products/42.

HTTP-metoder (CRUD-operationer)

GET

Henter data fra serveren. Ændrer ingenting.

GET /api/users/42
POST

Opretter ny data på serveren.

POST /api/users
PUT

Erstatter eksisterende data fuldstændigt.

PUT /api/users/42
PATCH

Opdaterer dele af eksisterende data.

PATCH /api/users/42
DELETE

Sletter data fra serveren.

DELETE /api/users/42

Praktisk eksempel: Bruger-API

Her er et komplet eksempel på hvordan en bruger-API typisk ser ud. Endpointet /api/users håndterer alle CRUD-operationer:

// Hent alle brugere

GET /api/users?page=1&limit=20
Accept: application/json

// Svar (200 OK):
{
  "data": [
    { "id": 1, "name": "Anna", "email": "anna@example.dk" },
    { "id": 2, "name": "Bo", "email": "bo@example.dk" }
  ],
  "pagination": { "page": 1, "total": 47, "limit": 20 }
}

// Opret ny bruger

POST /api/users
Content-Type: application/json

{ "name": "Clara", "email": "clara@example.dk" }

// Svar (201 Created):
{
  "id": 3,
  "name": "Clara",
  "email": "clara@example.dk",
  "created_at": "2026-04-10T10:30:00Z"
}

// Slet bruger

DELETE /api/users/3
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

// Svar (204 No Content)

HTTP-statuskoder

2xx

Succes

-200 OK
-201 Created
-204 No Content
3xx

Omdirigering

-301 Moved Permanently
-304 Not Modified
4xx

Klientfejl

-400 Bad Request
-401 Unauthorized
-403 Forbidden
-404 Not Found
-429 Too Many Requests
5xx

Serverfejl

-500 Internal Server Error
-502 Bad Gateway
-503 Service Unavailable

Autentificering

De fleste API'er kræver autentificering for at beskytte data og kontrollere adgang. De tre mest udbredte metoder er:

API-nøgle

Den simpleste metode. En unik nøgle sendes med hver forespørgsel, typisk som header eller query parameter.

X-API-Key: dk_live_abc123xyz

Bearer Token (JWT)

Brugeren logger ind og modtager en token der sendes med efterfølgende forespørgsler. Tokenen udløber efter en periode.

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...

OAuth 2.0

Den mest avancerede metode. Bruges når en tredjepartsapp skal have adgang til en brugers data – f.eks. "Log ind med Google". Involverer en autorisationsserver, access tokens og refresh tokens.

Best practices for API-design

+
Brug navneord i URL'er, ikke verber
/api/users (korrekt) vs. /api/getUsers (forkert)
+
Brug flertal for collections
/api/users, /api/products, /api/orders
+
Versionér din API
/api/v1/users eller Accept: application/vnd.api.v1+json
+
Returnér konsistente fejlsvar
{ "error": { "code": "NOT_FOUND", "message": "Bruger ikke fundet" } }
+
Implementér pagination
?page=2&limit=20 med total count i svaret
+
Brug HTTPS altid
Aldrig HTTP til produktion – data sendes ukrypteret
+
Rate limiting
Begræns antal forespørgsler per minut for at beskytte serveren

REST vs. alternativer

REST

Fordele

+Simpel og velforstået
+Bygger på HTTP-standarder
+Bred tooling-support

Ulemper

-Over-fetching/under-fetching
-Mange endpoints for kompleks data

Bedst til: De fleste web-applikationer og offentlige API'er

GraphQL

Fordele

+Klienten bestemmer data-shape
+Ét endpoint til alt
+Stærk type-system

Ulemper

-Mere kompleks setup
-Caching er sværere
-Overhead for simple queries

Bedst til: Komplekse frontends med varierende databehov

gRPC

Fordele

+Binært format (hurtigere)
+Stærke kontrakter (Protobuf)
+Bi-directional streaming

Ulemper

-Ikke browser-native
-Sværere at debugge
-Kræver kodegenerering

Bedst til: Microservices og intern service-kommunikation

REST API og databaser

En REST API er typisk et lag mellem klienten og databasen. API'en modtager HTTP-forespørgsler, oversætter dem til databaseforespørgsler, og returnerer resultatet som JSON. De mest populære database-valg til API-backends er:

-PostgreSQL: Det populære valg til kompleks data med relationer. Fuld ACID-support og avancerede features som JSONB.
-MongoDB: Dokumentdatabase der gemmer data som JSON-lignende dokumenter. Naturligt match med API-responses.
-Redis: In-memory database der ofte bruges til caching af API-responses og session management.
-Supabase: Open-source Firebase-alternativ der automatisk genererer en REST API fra din PostgreSQL-database.

Relaterede emner