REST vs GraphQL: Hvad er forskellen, og hvilken skal du bruge?

REST og GraphQL er to måder at designe en API på — den aftalte måde, hvorpå skærmene i din app (eller andre programmer) beder din backend om data. Med REST er der en separat URL for hver type ting, som /customers eller /orders, og hver returnerer en fast form af data. Med GraphQL er der normalt én URL, og kalderen sender en forespørgsel, der præcis angiver, hvilke felter den vil have tilbage. For de fleste apps bygget med AI er REST det enklere og bedre standardvalg.

Hvorfor det betyder noget, når du bygger med AI

Når du beder en AI-appbygger om "en app med en backend", skal den vælge, hvordan frontend og backend taler sammen. Du behøver ikke tage stilling til det hver gang — men du vil se begreberne i kode, i dokumentation og når du forbinder til eksterne tjenester. Nogle tjenester tilbyder kun den ene stil: mange tjenester udstiller REST-API'er, mens andre — Shopify og GitHub, for eksempel — også tilbyder eller foretrækker GraphQL. At kende forskellen hjælper dig med at forstå, hvad du ser, og undgå at tilføje kompleksitet, du ikke har brug for. Hvis "API" er nyt for dig, så start med hvad en API er.

En hverdagsanalogi

REST er en menu med faste retter på en restaurant. Hver ret (endpoint) kommer, som køkkenet har designet den. Bestiller du "kunde"-retten, får du hele tallerkenen — navn, e-mail, adresse, oprettelsesdato — selvom du kun ville have navnet. Vil du også have kundens seneste ordrer? Så er det en anden ret.

GraphQL er at bestille à la carte hos én tjener. Du skriver præcis, hvad du vil have: "kundens navn, og datoerne og totalerne for deres sidste tre ordrer." Én bestilling, én tallerken, kun det du bad om. Men køkkenet skal være indrettet til at håndtere enhver kombination, kunder kan skrive ned.

Den samme forespørgsel, begge veje

Lad os sige, at en kundeside har brug for en kundes navn plus deres tre seneste ordrer.

Med REST er det typisk to forespørgsler:

GET /api/customers/42
GET /api/customers/42/orders?limit=3

Det første svar kan indeholde mere, end siden har brug for:

{ "id": 42, "name": "Lena Park", "email": "lena@example.com", "address": "…", "createdAt": "…" }

Med GraphQL er det én forespørgsel, normalt et POST til et enkelt endpoint som /graphql, med en query:

query {
  customer(id: 42) {
    name
    orders(last: 3) {
      date
      total
    }
  }
}

Og svaret spejler forespørgslen præcis:

{
  "data": {
    "customer": {
      "name": "Lena Park",
      "orders": [
        { "date": "2026-09-20", "total": 48.0 },
        { "date": "2026-09-02", "total": 19.5 },
        { "date": "2026-08-15", "total": 72.25 }
      ]
    }
  }
}

Begge returnerer JSON. Forskellen er, hvem der bestemmer formen: ved REST gør serveren det; ved GraphQL gør kalderen det, inden for hvad serverens skema tillader.

Side om side

Hvor hver passer

Vælg REST, når:

• Du bygger en typisk app: et bookingsystem, et CRM, et dashboard, en butik.
• Én frontend taler med én backend, og du kontrollerer begge.
• Du vil have det enkleste at fejlsøge, cache og sikre.
• Andre tjenester skal kalde din app (webhooks og de fleste integrationer forventer REST-lignende endpoints).

Overvej GraphQL, når:

• Flere forskellige klienter — en hjemmeside, en mobilapp, partnerintegrationer — har brug for meget forskellige udsnit af de samme data.
• Dine data er dybt forbundne (produkter, varianter, anmeldelser, sælgere, lager), og skærmene skal kombinere dem på mange måder.
• Du bruger en tjeneste, der tilbyder GraphQL som sin hovedsagelige API.

En nyttig tommelfingerregel: Hvis du ikke er sikker på, at du har brug for GraphQL, har du sandsynligvis ikke brug for det endnu. Det er lettere at tilføje senere end at fjerne.

Centrale begreber

Almindelige misforståelser

• "GraphQL er nyere, så det er bedre." Det løser bestemte problemer. For en enkelt app med én frontend tilføjer det ofte arbejde uden meget gevinst.
• "GraphQL er en database." Det er det ikke. Det er et API-lag; bag det læser serveren stadig fra din database.
• "GraphQL er altid hurtigere." Færre forespørgsler kan hjælpe på langsomme mobilnetværk, men en ubegrænset forespørgsel kan hente enorme mængder data. Ydeevnen afhænger af backend.
• "REST betyder en streng standard." I praksis betyder "REST-API" løst sagt ressource-URL'er plus HTTP-metoder og JSON. Mange gode API'er bøjer de formelle regler.
• "Status 200 betyder, at det virkede." Ved GraphQL skal du tjekke errors-feltet — en forespørgsel kan delvist fejle og stadig returnere 200.

Hvad du skal spørge din AI-appbygger om

• "Brug en simpel REST-API med JSON, medmindre der er en tydelig grund til andet — forklar, hvis du mener, at GraphQL er nødvendigt."
• "List hvert endpoint, hvad det returnerer, og hvem der må kalde det."
• "Til kundesiden: returner kun de felter, siden bruger."
• "Tilføj paginering til listeendpoints, så de aldrig returnerer tusindvis af rækker på én gang."
• "Denne tjeneste har kun en GraphQL-API — kald den fra serveren, gem nøglen som en hemmelighed, og hent kun de felter, vi har brug for."
• "Returner korrekte HTTP-statuskoder og JSON-fejlbeskeder."

REST og GraphQL i Mythex

Mythex' dokumentation indeholder en opskrift på at bygge en REST-API-backend med en startprompt, og en backend kan køre i Node, Python (FastAPI), C# eller Java sammen med din webapp. Dokumentationen beskriver ikke en GraphQL-skabelon, så hvis du vil have en, skal du bede om det udtrykkeligt og sige hvorfor. Kald af en tredjeparts GraphQL-API fungerer som enhver anden ekstern tjeneste — se integrer enhver API. Relateret læsning: frontend vs backend og sådan bygger du en REST-API.

Spørgsmål