REST vs GraphQL: Hva er forskjellen, og hva bør du bruke?

REST og GraphQL er to måter å designe et API på — den avtalte måten skjermene i appen din (eller andre programmer) ber backenden din om data. Med REST finnes det en egen URL for hver type ting, for eksempel /customers eller /orders, og hver returnerer en fast form på dataene. Med GraphQL finnes det vanligvis én URL, og den som kaller sender en spørring som lister nøyaktig hvilke felt den vil ha tilbake. For de fleste apper bygget med AI er REST det enklere og bedre standardvalget.

Hvorfor dette betyr noe når du bygger med AI

Når du ber en AI-byggeverktøy om «en app med en backend», må den velge hvordan grensesnittet og backenden snakker sammen. Du trenger ikke bestemme dette hver gang, men du vil se begrepene i kode, i dokumentasjon og når du kobler til eksterne tjenester. Noen tjenester tilbyr bare én stil: mange tjenester har REST-API-er, mens andre — for eksempel Shopify og GitHub — også tilbyr eller foretrekker GraphQL. Å kjenne forskjellen hjelper deg å forstå det du ser, og unngå å legge til kompleksitet du ikke trenger. Hvis «API» er nytt for deg, start med hva et API er.

En hverdagslig analogi

REST er en fast meny på en restaurant. Hver rett (endepunkt) kommer slik kjøkkenet har laget den. Bestiller du «kunde»-retten, får du hele tallerkenen — navn, e-post, adresse, registreringsdato — selv om du bare ville ha navnet. Vil du også ha kundens nylige bestillinger? Det er en ny rett.

GraphQL er å bestille à la carte fra én servitør. Du skriver ned nøyaktig hva du vil ha: «kundens navn, og datoene og summene for de tre siste bestillingene». Én bestilling, én tallerken, bare det du ba om. Men kjøkkenet må være satt opp til å håndtere enhver kombinasjon kunder kan finne på å skrive ned.

Samme forespørsel, begge veier

Anta at en kundeside trenger en kundes navn og de tre siste bestillingene.

Med REST er det vanligvis to forespørsler:

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

Det første svaret kan inneholde mer enn siden trenger:

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

Med GraphQL er det én forespørsel, vanligvis en POST til ett enkelt endepunkt som /graphql, med en spørring:

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

Og svaret speiler spørringen nøyaktig:

{
  "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. Forskjellen er hvem som bestemmer formen: i REST gjør serveren det; i GraphQL gjør den som kaller det, innenfor det serverens skjema tillater.

Side-by-side-sammenligning

Hvor hver passer

Velg REST når:

• Du bygger en typisk app: et bookingsystem, et CRM, et dashbord, en nettbutikk.
• Ett grensesnitt snakker med én backend, og du kontrollerer begge.
• Du vil ha det enkleste å feilsøke, cache og sikre.
• Andre tjenester skal kalle appen din (webhooks og de fleste integrasjoner forventer REST-lignende endepunkter).

Vurder GraphQL når:

• Flere ulike klienter — et nettsted, en mobilapp, partnerintegrasjoner — trenger svært ulike deler av de samme dataene.
• Dataene dine er sterkt koblet (produkter, varianter, anmeldelser, selgere, lager), og skjermene må kombinere dem på mange måter.
• Du bruker en tjeneste som tilbyr GraphQL som sitt hoved-API.

En nyttig regel: hvis du er usikker på om du trenger GraphQL, gjør du sannsynligvis ikke det ennå. Det er lettere å legge til senere enn å fjerne.

Sentrale begreper

Vanlige misforståelser

• «GraphQL er nyere, så det er bedre.» Det løser bestemte problemer. For én app med ett grensesnitt gir det ofte mer arbeid uten stor nytte.
• «GraphQL er en database.» Det er det ikke. Det er et API-lag; bak det leser serveren fortsatt fra databasen din.
• «GraphQL er alltid raskere.» Færre forespørsler kan hjelpe på trege mobilnett, men en ubegrenset spørring kan laste enorme mengder data. Ytelsen avhenger av backenden.
• «REST betyr en streng standard.» I praksis betyr «REST-API» løst sett ressurs-URL-er pluss HTTP-metoder og JSON. Mange gode API-er bøyer de formelle reglene.
• «Status 200 betyr at det fungerte.» Med GraphQL må du sjekke feltet errors — en forespørsel kan delvis feile og likevel returnere 200.

Hva du bør be AI-byggeren om

• «Bruk et enkelt REST-API med JSON med mindre det finnes en tydelig grunn til noe annet — forklar hvis du mener GraphQL trengs.»
• «List opp hvert endepunkt, hva det returnerer, og hvem som har lov til å kalle det.»
• «For kundesiden, returner bare feltene siden bruker.»
• «Legg til paginering på listeendepunkter, slik at de aldri returnerer tusenvis av rader på én gang.»
• «Denne tjenesten har bare et GraphQL-API — kall den fra serveren, behold nøkkelen i en hemmelighet, og be bare om feltene vi trenger.»
• «Returner riktige HTTP-statuskoder og JSON-feilmeldinger.»

REST og GraphQL i Mythex

Mythex sin dokumentasjon har en oppskrift for å bygge en REST-API-backend med en startprompt, og en backend kan kjøre i Node, Python (FastAPI), C# eller Java sammen med nettappen din. Dokumentasjonen beskriver ingen GraphQL-mal, så hvis du vil ha en, be eksplisitt om den og si hvorfor. Å kalle et GraphQL-API fra en tredjepart fungerer som alle andre eksterne tjenester — se integrer et hvilket som helst API. Relatert lesing: frontend vs backend og hvordan bygge et REST-API.

Spørsmål