Når du skal i gang med at bygge en API, falder tankerne med det samme på REST. Det har været standarden i to årtier, og standarder er trygge. Men GraphQL dukker hele tiden op, og GraphQL vs. REST er nu en af de første arkitektoniske beslutninger, et produktteam skal tage.
Så lad os springe spændingen over. Vælg GraphQL, når mange forskellige klienter har brug for forskellige former af de samme data. Vælg REST, når caching, overvågning og operationel enkelhed betyder mere end fleksibilitet i forespørgsler. De fleste organisationer ender med at køre begge dele, og det er helt fint.
Tænk på det som et køkken. REST serverer den samme menu til alle borde, og hvis du vil have tilbehøret, må du bestille en ekstra ret. GraphQL giver dig en bestillingsblok og lader dig skrive præcis, hvad du vil have. Maden er den samme, og køkkenet er det samme. Det, der ændrer sig, er, hvem der bestemmer anretningen, og hvad den beslutning koster dig senere.
Det er den sidste del, denne artikel bruger det meste af sin tid på: funktionerne, de reelle forskelle samt konsekvenserne for omkostninger, risici og levering ved at vælge den ene frem for den anden.
GraphQL er et forespørgselssprog til API'er, der muliggør deklarativ datahentning. Sagt på almindeligt dansk: Klienten angiver præcis, hvilke data den ønsker, og får nøjagtigt det retur. Det gør også API'er lettere at videreudvikle over tid. Opførslen er fastlagt i en offentlig specifikation, så det er en reel standard frem for et produkt fra en enkelt leverandør.
Tre ting, det ikke er, da alle tre emner altid dukker op til det første møde.
GraphQL blev udviklet internt af Facebook (nu Meta) i 2012, før det blev open source i september 2015. Det blev skabt i fællesskab af Lee Byron, Nick Schrock og Dan Schafer mens de arbejdede på Facebooks mobilapplikationer. Hav den kontekst i baghovedet, for den forklarer de fleste af de designbeslutninger, der følger.
Planen om at flytte projektet til en leverandørneutral GraphQL Foundation under Linux Foundation blev annonceret i november 2018, og fonden blev formelt etableret i 2019.
Det er afgørende, at specifikationen ikke er fastlåst i 2018. September 2025-udgaven, den første fulde udgave siden oktober 2021, introducerede Schema Coordinates (maskin- og menneskelæsbare adresser til schema-elementer), OneOf-inputobjekter (gensidigt udelukkende inputs udtrykt i schemaet) og beskrivelser i eksekverbare dokumenter. Flere af disse blev designet med henblik på codegen-værktøjer og LLM-drevne agenter, hvilket er vigtigt, hvis dit API i stigende grad bliver brugt af AI-værktøjer frem for kun af mennesker.
GraphQL bruges af teams af alle størrelser, på tværs af mange miljøer og sprog. De mest kendte brugere er Facebook, GitHub, Pinterest, Shopify, Airbnb og Netflix.
Før vi sammenligner noget som helst, er her en simpel GraphQL-forespørgsel, der henter en bruger sammen med vedkommendes navn og alder:
{
user(id: "1") {
name
age
}
}Og det JSON-svar, du får tilbage:
{
"data": {
"user": {
"name": "João Inez",
"age": 29
}
}
}Bemærk, at svaret spejler forespørgslen, felt for felt. Det er hele pointen med den deklarative del: Du skriver JSON-objekter uden værdierne, og du kan læse, hvad en anmodning vil returnere, uden nogensinde at køre den.
REST blev defineret af Roy Fielding, datalogen, der fastlagde principperne i sin ph.d.-afhandling i 2000.
REST (Representational State Transfer) er en softwarearkitektonisk stil, der definerer en række begrænsninger, som gør en webtjeneste til et ægte RESTful API. Disse begrænsninger er:
Når du kombinerer disse fem, får du klienter, formidlere og ressource-servere, der alle kommunikerer via et fælles, cache-egnet interface. Denne egenskab er fundamentet for alt det, der følger i denne artikel. Fordi interfacet er ensartet og adresserbart, kan alt, der ligger imellem – fra en browser-cache til et content delivery network (CDN) – agere på et svar uden at forstå indholdet.
To årsager fik virksomheder som Facebook, Netflix og Coursera til at søge mod alternativer:
Går man et skridt videre, er den egentlige årsag dataenes struktur. De fleste data i moderne web- og mobilapplikationer er graf-baserede – et netværk af forbundne entiteter frem for en stak flade tabeller. Nyhedsartikler har kommentarer, og disse kommentarer har likes eller spam-markeringer, oprettet eller rapporteret af brugere. At hente dette via ressource-per-endpoint-kald betyder, at man skal gennemløbe grafen én forespørgsel ad gangen, hvilket er præcis så langsomt, som det lyder.
Derfor begyndte Facebook at bygge GraphQL. Netflix og Coursera arbejdede på deres egne alternativer på samme tid. Efter at Facebook gjorde GraphQL open source, opgav Coursera deres egne tiltag og tog den nye teknologi til sig. Netflix fortsatte og gjorde senere Falcor, et JavaScript-bibliotek, der modellerer fjernlagrede data som én virtuel JSON-graf, open source. Falcor er i dag stort set inaktivt, så betragt det som en historisk fodnote frem for en aktuel mulighed.
GraphQL tilbyder et forespørgselssprog, der lader klienter anmode om præcis de data, de har brug for. REST er afhængig af faste slutpunkter og serverdefinerede datastrukturer. Om GraphQL er "bedre", afhænger af dine krav og hvor meget fleksibilitet dit projekt har brug for: GraphQL vinder på klientfleksibilitet og hastighed i front-end-levering; REST vinder på caching, overvågning og operationel modenhed. Amazons egen beslutningsguide til GraphQL opstiller den samme afvejning i forhold til de samlede ejeromkostninger, hvilket er en nyttig second opinion, når du skal opbygge business casen internt.
Lad os gennemgå et praktisk eksempel, punkt for punkt.
Forestil dig, at du har en blog, og du vil have forsiden til at vise alle de nyeste indlæg. Du skal hente indlæggene, så du ville sandsynligvis skrive noget i denne stil:
GET /api/posts
[
{ "id": 1, "title": "GraphQL vs REST", "subtitle": "Choosing an API", "date": "2026-02-21" },
{ "id": 2, "title": "Scaling a mobile back end", "subtitle": "Lessons learned", "date": "2026-02-14" }
]Men hvad nu, hvis du også vil have forfatteren med? Tre muligheder:
1. Hent forfatterne fra en anden ressource:
GET /api/posts
GET /api/authors?ids=1,2
[
{ "id": 1, "name": "João Inez" },
{ "id": 2, "name": "Ana Silva" }
]2. Rediger ressourcen, så den også returnerer forfatteren:
GET /api/posts
[
{
"id": 1,
"title": "GraphQL vs REST",
"subtitle": "Choosing an API",
"date": "2026-02-21",
"author": { "id": 1, "name": "João Inez" }
}
]3. Opret en ressource, der returnerer indlæggene sammen med forfatteren:
GET /api/posts-with-authors
[
{
"id": 1,
"title": "GraphQL vs REST",
"author": { "id": 1, "name": "João Inez" }
}
]Hver mulighed løser problemet, men skaber samtidig et nyt. Lad os tage dem én ad gangen.
Med den første tilgang, hvor du henter forfatterne fra en anden ressource, ender du med to serverforespørgsler i stedet for én. Skalerer du det op, får du flere forespørgsler til flere slutpunkter bare for at samle en enkelt visning. På en mobilforbindelse er hver tur-retur-forespørgsel lig med latenstid, som brugeren kan mærke med det samme.
Med GraphQL sker det ikke. Én forespørgsel, ingen ekstra ture:
{
posts {
title
subtitle
date
author {
name
}
}
}{
"data": {
"posts": [
{
"title": "GraphQL vs REST",
"subtitle": "Choosing an API",
"date": "2026-02-21",
"author": { "name": "João Inez" }
}
]
}
}Den anden tilgang, hvor man ændrer ressourcen til også at returnere forfatteren, løser det umiddelbare problem fint. Men så skaber den i stilhed et nyt problem et andet sted i din applikation. Over-fetching.
Tilbage til din blog. Denne gang har du også en sidebjælke, der viser månedens mest populære indlæg med titler, undertitler og datoer, og den bruger /api/posts ressource. Du har ændret ressourcen, så den nu også returnerer forfatteren. Sidepanelet har ikke brug for forfatteren, men alle klienter, der kalder det endpoint, betaler for det alligevel.
For brugere med begrænset data og langsomme forbindelser er unødvendige data en reel omkostning. GraphQL lader klienten bede om præcis de felter, den har brug for, og intet andet, så problemet opstår aldrig:
{
posts(sort: "monthly_top", limit: 5) {
title
subtitle
date
}
}{
"data": {
"posts": [
{ "title": "GraphQL vs REST", "subtitle": "Choosing an API", "date": "2026-02-21" }
]
}
}Hvilket bringer os til den tredje tilgang: at oprette en ressource, der returnerer indlæg sammen med forfatteren. At strukturere endpoints omkring visningerne i dit projekt er et ret almindeligt mønster.
Det løser ganske vist ovenstående problem. Men det gør også front-end-udviklingen langsommere, fordi hver specifik visning nu kræver sit eget specifikke endpoint. Hvis en visning har brug for et nyt felt, går front-end-arbejdet i stå, indtil back-end-teamet har frigivet opdateringen. Den koordineringsomkostning er noget, teams konsekvent undervurderer.
GraphQL giver i stedet klienten blokken med bestillingssedler. At tilføje et felt kræver ikke en back-end-release fra nogen. Du går fra dette:
{
posts {
title
author {
name
}
}
}Til dette:
{
posts {
title
subtitle
date
author {
name
avatarUrl
}
}
}Der er ingen back-end-ændring involveret.
| Dimension | GraphQL | REST |
|---|---|---|
| Datahentning | Klienten angiver felterne; én anmodning returnerer præcis dem | Serveren definerer svaret; relaterede data kræver flere kald |
| Slutpunkter (Endpoints) | Ét slutpunkt for hele skemaet | Ét slutpunkt pr. ressource |
| Caching | Bygget af dig, i klienten eller i et gemt forespørgselslag (persisted query) | Gratis via HTTP; fungerer i browseren og på CDN-niveau |
| Fejlhåndtering | 200 OK med et fejl-array; kræver værktøjer, der understøtter GraphQL | HTTP-statuskoder, som forstås af alle overvågningsværktøjer |
| Autorisation | Håndhæves pr. felt eller pr. resolver | Håndhæves pr. slutpunkt |
| Versionsstyring | Additiv; gamle felter markeres som @deprecated | Eksplicit, typisk fra /v1/ til /v2/ |
| Hastighedsbegrænsning (Rate limiting) | Efter forespørgselsomkostning og dybde, da anmodningsomkostningen varierer | Efter anmodninger pr. minut, da omkostningen er nogenlunde ensartet |
| Bedste anvendelse | Flere forskellige klienter på ét fælles backend | Offentlige API'er, læsetung og cachebar trafik |
Et hurtigt overblik over forskellene og hvad de hver især koster dig:
Som nævnt erstatter GraphQL ikke REST. Ser man bort fra forskellene, har de to meget til fælles, hvilket er en del af grunden til, at valget mellem REST og GraphQL sjældent er enten-eller:
Query og Mutation -typer spiller samme rolle som listen over slutpunkter i et REST API. En mutation er i øvrigt blot en GraphQL-operation, der skriver data i stedet for at læse dem.GraphQL blev bygget til mobilklienter, og det er stadig her, teknologien for alvor viser sit værd. En mobilapp kører på en forbindelse, du ikke har kontrol over, så hvert unødvendigt felt og hver ekstra forespørgsel skaber en forsinkelse, som brugeren kan mærke. Tænk tilbage på eksemplet med over-fetching: sidepanelet skulle bruge tre felter, men det modificerede REST-endepunkt returnerede fem, inklusive et indlejret forfatterobjekt, som visningen aldrig rendrerede. Ganger man det op på tværs af en hel skærm på et dårligt netværk, så kan det mærkes.
Jo flere klienter du betjener fra samme backend, og jo mere de adskiller sig fra hinanden, desto vigtigere bliver dette. Det er også en god løsning, hvor frontenden udvikler sig hurtigere end backenden, fordi skemaet absorberer ændringer, der ellers ville kræve nye endepunkter.
Dette er den arkitektur, vi oftest bygger til: et API med lav latenstid, der betjener flere klienter fra én backend. På TrustPortalleverede vi for eksempel både web- og mobilapplikationen sammen med de bagvedliggende API-tjenester, optimeret til lav latenstid og bygget til at køre på mange sprog for en international brugerbase. Det er præcis den situation, hvor et enkelt, klienttilpasset datalag betaler sig, uanset om du tilgår det via GraphQL eller et omhyggeligt designet REST API.
GraphQL er et stærkt værktøj, men det er ikke en komplet løsning. Hvis noget af følgende er vigtigt for dit projekt, bør du overveje REST.
Alle browsere leveres med en HTTP-cache der undgår genhentning af ressourcer og finder ud af, hvornår to ressourcer er ens. Det koster dig intet, alle forstår det, og det fungerer både i CDN'et og i browseren.
GraphQL har ingen globalt unik identifikator for et objekt på URL-niveau, fordi alle forespørgsler går til det samme endepunkt, normalt via POST. For at få caching skal du selv bygge det, enten i klienten (Apollo Client, Relay, urql) eller i et lag med persistente forespørgsler foran serveren. Det er reelt arbejde og en reel driftsmæssig flade. Et REST-API får det direkte fra protokollen og fungerer naturligt sammen med en cache som Redis eller Memcached.
Med REST kan du bygge et overvågningssystem oven på statuskoder. En 500 er en hændelse, en 404 er en manglende ressource, en 200 betyder, at alt er i orden. GraphQL giver dig intet af dette, da det returnerer 200 OK for næsten alt, inklusive fejl. En typisk GraphQL-fejl ser således ud:
{
"errors": [
{
"message": "Cannot query field \"avatarURL\" on type \"Author\".",
"locations": [{ "line": 5, "column": 7 }],
"path": ["posts", 0, "author"]
}
],
"data": null
}Håndtering og overvågning af forskellige fejlscenarier fra det svar er mere besværligt, og standardovervågning baseret på HTTP-statuskoder vil slet ikke opfange fejlen. Du har brug for GraphQL-specifik instrumentering, før du overhovedet overvejer produktion.
Med GraphQL kan du forespørge præcis, hvad du vil, når du vil, og den frihed har sikkerhedsmæssige konsekvenser. Hvis en ondsindet aktør sender en tung, indlejret forespørgsel for at overbelaste din server eller database, og din server ikke har beskyttelse på plads, er du sårbar over for denial-of-service (DoS)-angreb. OWASP GraphQL Cheat Sheet er direkte på dette punkt: forespørgselsdybde og -mængde er som standard ubegrænsede, så du er nødt til selv at tilføje begrænsninger. Et REST-endepunkt har en begrænset omkostning i kraft af sin opbygning. Det har en GraphQL-forespørgsel ikke.
De fleste sammenligninger stopper ved over-fetching. Men det er de operationelle forskelle, der reelt afgør resultatet, når først API'et er live, og nogen står med ansvaret for det.
Autentificering fungerer stort set ens i begge tilfælde: et token i en header, der valideres pr. anmodning. Autorisation er en anden sag. I REST ligger tilladelseskontrollen ved endpointet, og du kan se, hvem der må kalde hvad, ved at læse rutetabellen. I GraphQL kan én forespørgsel gennemløbe flere typer i en enkelt anmodning, så tilladelser skal håndhæves pr. felt eller pr. resolver. Det kræver mere kode, og den kode skal være komplet: et enkelt ubeskyttet felt i en indlejret type vil udlevere de data, som endpointet ovenover ellers beskyttede. OWASP anbefaler at håndhæve autorisation på både noder og kanter netop fordi dette hul er så let at overse.
Rate limiting baseret på anmodninger pr. minut fungerer fint til REST, hvor anmodninger koster nogenlunde det samme. Det fungerer ikke til GraphQL, hvor én anmodning kan være triviel, mens den næste kan sammenkoble halvdelen af din database. GraphQL-API'er har brug for begrænsninger på forespørgselsdybde, kompleksitetsscoring, der tildeler en omkostning til hvert felt, og ofte persisted queries, som kun tillader et forhåndsgodkendt sæt af operationer i produktion. Afsæt tid til det arbejde nu, fremfor at opdage behovet under en hændelse.
REST bruger versionsstyring via URL, /v1/ til /v2/, hvilket er eksplicit, let at kommunikere og betyder, at du skal vedligeholde begge dele. GraphQL omgår versionsstyring: du tilføjer felter og markerer gamle som forældede med @deprecated -direktivet, og klienterne migrerer i deres eget tempo. Dette er yderst nyttigt for et skema, der betjener mange klienter, men det medfører én forpligtelse: hold øje med feltbrug, ellers bliver de forældede felter aldrig fjernet, og skemaet vil vokse i det uendelige.
Da en GraphQL-resolver kører pr. felt, kan en forespørgsel på 50 indlæg med tilhørende forfattere udløse 51 databaseforespørgsler: én for indlæggene og én pr. forfatter. Dette er det N+1-problem, og det er den hyppigste årsag til, at en funklende ny GraphQL-API ender med at være langsommere end den REST-API, den erstattede. Løsningen er batching, hvor man samler de 50 forfatteropslag i ét databasekald, typisk ved hjælp af DataLoader eller et tilsvarende bibliotek. Det er ikke valgfrit ved nogen form for reel belastning. REST slipper heller ikke for N+1, men forespørgselsmønsteret bag et endpoint er fastlagt, så det opdages under udviklingen frem for under produktionsbelastning.
Én ting har ændret præmissen for denne beslutning siden de tidlige dage med GraphQL: Man bygger sjældent én monolitisk graf længere. Federation gør det muligt for flere teams hver især at eje en undergraf, som en gateway samler til én enkelt graf, som klienten forespørger, som var det ét samlet API. Hvis din organisation er stor nok til, at "GraphQL vs. REST" i virkeligheden handler om, "hvordan mange teams eksponerer ét sammenhængende API", så er dette mønsteret, du bør overveje.
Økosystemet er også ved at standardisere på dette område. GraphQL Foundations arbejde med Composite Schema Specification har til formål at gøre grafer på tværs af flere tjenester bærbare mellem gateways, frem for at de er låst til én leverandørs implementering. Det er værd at nævne i enhver sammenligning i 2026, fordi det ændrer det operationelle regnestykke: Federation tilføjer et kompositions- og gateway-lag, som skal vedligeholdes, oveni alt det, der er nævnt i afsnittet ovenfor.
REST har ikke nogen direkte modpart. Det tætteste, man kommer, er en API-gateway, der binder flere tjenester sammen, men uden et fælles typesystem på tværs af dem. Hvis målet er en samlet, stærkt typet graf på tværs af mange teams, så er det et point til GraphQL. Hvis hver tjeneste kan stå alene bag sine egne endpoints, holder REST tingene simplere.
GraphQL vs. REST er ikke hele billedet. gRPC er en stærk mulighed til intern trafik mellem tjenester, hvor en binær protokol og genererede klienter slår menneskeligt læsbar JSON, og hvor intet kalder dig fra en browser. tRPC er værd at kigge nærmere på, når begge ender af stacken er TypeScript i samme kodebase, da det giver dig end-to-end typesikkerhed uden et skemasprog eller et trin til kodegenerering. Vær dog opmærksom på, at det ikke kan betjene en klient, du ikke selv ejer.
Den grove opdeling: REST til offentlige og tredjeparts-API'er, GraphQL til varierede førstepartsklienter, gRPC til intern trafik mellem tjenester, tRPC til full-stack TypeScript-produkter. Store virksomheder kører ofte med mere end én af disse. Det er en normal slutstatus, ikke et tegn på manglende standardisering.
To funktioner har ingen modpart i REST, og begge ændrer måden, teams arbejder på, frem for hvordan API'et performer.
GraphQL bruger sit eget typesystem til at definere API'ets skema med en syntaks kaldet Schema Definition Language (SDL). Skemaet er en kontrakt mellem server og klient, der fastlægger, hvordan en klient kan tilgå dataene.
type Author {
id: ID!
name: String!
posts: [Post!]!
}
type Post {
id: ID!
title: String!
subtitle: String
date: String!
author: Author!
}
type Query {
posts(limit: Int): [Post!]!
user(id: ID!): Author
}Når skemaet først eksisterer, kan front-end- og back-end-teams arbejde uafhængigt af hinanden, fordi front-enden kan testes mod mock-data genereret ud fra det. Front-enden kan også læse skemaets typer, forespørgsler og mutationer via introspection, den indbyggede evne til at forespørge selve skemaet og få en liste over tilgængelige typer og felter retur. Du får typesikkerhed oveni, hvilket fanger typefejl tidligt i begge ender. Schema Coordinates fra specifikationen fra september 2025 gør det muligt at adressere det introspekterede skema på en standardiseret måde, hvilket er praktisk til kodegenerering, registre og AI-værktøjer.
GraphQL-IDE'en er en af de mest nyttige dele af værktøjskæden. Den udnytter skemaets selvdokumenterende natur og fjerner det meste af gættearbejdet i forbindelse med integration.
Brug en aktuel og vedligeholdt klient som f.eks. GraphiQL (vedligeholdt af GraphQL Foundation), Apollo Sandbox eller Altair til at inspicere dit skema og køre forespørgsler og mutationer mod dit API, uden at du behøver at skrive en klient først.
En bemærkning om værktøjernes aktualitet: den ældre GraphQL Playground er blevet pensioneret og fjernet fra Apollo Server 3. Den har ikke været vedligeholdt siden 2019 og indeholder kendte sikkerhedssårbarheder, så foretræk GraphiQL, Apollo Sandbox eller Altair til nye projekter.
Den tekniske sammenligning afgør sjældent sagen alene. Det, der gør udslaget, er leveringshastighed, driftsomkostninger og den risiko, du påtager dig.
Dette er den tjekliste, vores ingeniører gennemgår under API-discovery, før en eneste linje kode skrives. Besvar alle fem. Hvis tre eller flere peger i samme retning, er det et klart signal.
Besvar disse spørgsmål ærligt, og beslutningen er som regel allerede truffet for dig. Det mønster, vi oftest ser i mobilprodukter, er et GraphQL-lag foran eksisterende REST-tjenester, som implementeres én klient ad gangen frem for som en samlet overgang.
GraphQL giver dig et fleksibelt, deklarativt udviklingsmiljø, og det løser reelle problemer, som REST efterlader hos klienten. Det har et stort community, et modent økosystem og implementeringer i flere populære sprog, herunder JavaScript, Go og Java. Dette indlæg gennemgår det, der er væsentligt for din beslutning. GraphQL-specifikationen går væsentligt mere i dybden med selve sproget.
Bygger du et API primært til en mobilapplikation? GraphQL er et fornuftigt førstevalg, da båndbredde og svartider er noget, dine brugere kan mærke. Har du brug for edge-caching, moden overvågning og forudsigelige anmodningsomkostninger? REST er stadig det bedste standardvalg.
Så er GraphQL enden på REST? Nej, selvfølgelig ikke. Det er ikke en perfekt teknologi, og den har ulemper, som REST ikke har. Hvis man koger hele sammenligningen ned til én linje, lyder den: GraphQL vs. REST handler om dine klienter, dit team og din drift – aldrig om, hvilken teknologi der ser mest moderne ud.
Nej. Udbredelsen af GraphQL vokser fortsat, men REST er stadig standarden for offentlige og tredjeparts-API'er, og de fleste organisationer benytter begge dele. GraphQL bliver typisk tilføjet foran eksisterende REST-tjenester frem for at erstatte dem.
For en klient, der har brug for data fra flere ressourcer, ja, fordi én forespørgsel erstatter flere roundtrips, og payloadet indeholder ingen ubrugte felter. For en enkelt cachebar ressource er REST normalt hurtigere, da en HTTP-cache eller et CDN kan levere den uden overhovedet at kontakte din server. Et GraphQL-API uden batching, der rammes af N+1-problemet, kan være betydeligt langsommere end det REST-API, det erstattede.
Når din trafik er læsetung og leveres fra et CDN, når du har én klient med en stabil datamodel, når din alarmering er bygget på HTTP-statuskoder, eller når teamet, der vedligeholder API'et, er lille og allerede har for travlt.
Ja, og det er det mest almindelige mønster. Et GraphQL-lag placeres foran eksisterende REST-tjenester og løser felter ved at kalde dem, hvilket gør det muligt at migrere én klient ad gangen i stedet for at skulle foretage et fuldt skift.
Serveren er den mindste del. Skemadesign, autorisering på feltniveau, batching, caching og klient-migreringen er der, hvor arbejdet ligger, og opgaven er først fuldført, når de gamle endpoints er udfaset. Planlæg det pr. klient frem for som ét samlet projekt.
Ingen af dem er i sig selv mere sikre, men de fejler på forskellige måder. REST har en begrænset omkostning pr. endpoint og tilladelseskontrol ét sted. GraphQL kræver autorisering på feltniveau, begrænsninger på forespørgselsdybde og kompleksitet samt typisk persisted queries, da en enkelt forespørgsel kan være vilkårligt dyr og kan tilgå typer, som kalderen ikke burde have adgang til. OWASP GraphQL Cheat Sheet er standardreferencen til at sikre dette.
Federation gør det muligt for flere teams hver især at eje en subgraph, som en gateway samler til én samlet graf, som klienten forespørger som ét API. Composite Schema Specification er ved at standardisere, hvordan disse grafer sammensættes på tværs af gateways. Det er velegnet til store organisationer, der eksponerer ét sammenhængende API fra mange tjenester, på bekostning af et ekstra lag til sammensætning og gateway, der skal driftes.
Den nuværende stabile udgave af GraphQL-specifikationen er September 2025-udgaven, den første fulde udgave siden oktober 2021. Den tilføjede Schema Coordinates, OneOf-inputobjekter og beskrivelser af eksekverbare dokumenter, hvoraf flere er målrettet codegen-værktøjer samt LLM- eller agent-værktøjer.
Skal du vælge mellem GraphQL og REST til et produkt, du er ved at bygge? Vi designer og bygger API'er til web- og mobilprodukter, lige fra platforme med lav latenstid som TrustPortal til forbrugerprodukter med høj volumen som Game Achievements. Vi tager gerne en snak om fordele og ulemper i forhold til jeres egne klienter, team og roadmap, før I beslutter jer. Kontakt vores team.
Webudvikler, der almindeligvis skriver null i stedet for nul. Elsker at udforske Javascripts funktionelle stil.
People who read this post, also found these interesting:
.webp)
