När du sätter dig ner för att bygga ett API går tankarna direkt till REST. Det har varit standard i två decennier, och standardval är bekväma. Men GraphQL dyker ständigt upp i sammanhanget, och GraphQL vs REST är numera ett av de första arkitekturbesluten ett produktteam behöver fatta.
Så låt oss gå rakt på sak. Välj GraphQL när många olika klienter behöver olika former av samma data. Välj REST när cachning, övervakning och operativ enkelhet väger tyngre än flexibilitet i frågorna. De flesta organisationer slutar med att köra båda, och det går alldeles utmärkt.
Se det som ett kök. REST serverar samma fasta meny till alla bord, och om du vill ha ett tillbehör beställer du en extra rätt. GraphQL ger dig en beställningsblock och låter dig skriva ner exakt vad du vill ha. Maten är densamma, och köket är detsamma. Det som skiljer sig är vem som bestämmer vad som hamnar på tallriken, och vad det beslutet kostar dig i längden.
Det är den sista delen som den här artikeln fokuserar på: funktionerna, de faktiska skillnaderna samt konsekvenserna för kostnad, risk och leverans vid val av det ena framför det andra.
GraphQL är ett frågespråk för API:er som möjliggör deklarativ datahämtning. Enkelt förklarat: klienten anger exakt vilken data den vill ha och får exakt det tillbaka. Det gör också API:er lättare att vidareutveckla över tid. Beteendet fastställs i en offentlig specifikation, så det är en genuin standard snarare än en enskild leverantörs produkt.
Tre saker det inte är, eftersom alla tre brukar komma upp vid första mötet.
GraphQL utvecklades internt av Facebook (nu Meta) 2012 innan det blev open source i september 2015. Det skapades av Lee Byron, Nick Schrock och Dan Schafer medan de arbetade med Facebooks mobilapplikationer. Ha det sammanhanget i åtanke, eftersom det förklarar de flesta av designbesluten som följer.
Avsikten att flytta projektet till en leverantörsneutral GraphQL Foundation under Linux Foundation tillkännagavs i november 2018, och stiftelsen etablerades formellt 2019.
Det är viktigt att notera att specifikationen inte är låst vid 2018. September 2025-utgåvan, den första fullständiga utgåvan sedan oktober 2021, introducerade Schema-koordinater (maskin- och mänskligt läsbara adresser för schemaelement), OneOf-indataobjekt (ömsesidigt uteslutande indata som uttrycks i schemat), och beskrivningar i körbara dokument. Flera av dessa var utformade med kodgenereringsverktyg och LLM-drivna agenter i åtanke, vilket är betydelsefullt om ditt API i allt högre grad används av AI-verktyg snarare än bara av människor.
GraphQL används av team i alla storlekar, i många olika miljöer och med olika programmeringsspråk. De mest kända användarna är Facebook, GitHub, Pinterest, Shopify, Airbnb och Netflix.
Innan vi jämför något, här är en enkel GraphQL-fråga som hämtar en användare tillsammans med dennes namn och ålder:
{
user(id: "1") {
name
age
}
}Och JSON-svaret du får tillbaka:
{
"data": {
"user": {
"name": "João Inez",
"age": 29
}
}
}Lägg märke till att svaret speglar frågan, fält för fält. Det är själva kärnan i den deklarativa aspekten: du skriver JSON-objekt utan värden, och du kan läsa vad en förfrågan kommer att returnera utan att någonsin köra den.
REST definierades av Roy Fielding, datavetaren som fastställde dess principer i sin doktorsavhandling år 2000.
REST (Representational State Transfer) är en mjukvaruarkitektonisk stil som definierar en uppsättning begränsningar som gör en webbtjänst till ett äkta RESTful-API. Dessa begränsningar är:
Slår man ihop dessa fem får man klienter, mellanhänder och resursservrar som alla kommunicerar via ett gemensamt, cachebart gränssnitt. Den egenskapen är vad allt senare i den här artikeln kretsar kring. Eftersom gränssnittet är enhetligt och adresserbart kan allt som finns däremellan, från en webbläsarcache till ett innehållsleveransnätverk (CDN), agera på ett svar utan att behöva förstå vad det innehåller.
Två anledningar fick företag som Facebook, Netflix och Coursera att söka sig till alternativ:
Om man går ett steg längre är den verkliga orsaken datastrukturen. Det mesta av datan i moderna webb- och mobilapplikationer är grafbaserad – ett nätverk av sammankopplade entiteter snarare än en hög med platta tabeller. Nyhetsartiklar har kommentarer, och dessa kommentarer har gilla-markeringar eller spam-flaggor, skapade eller rapporterade av användare. Att hämta detta genom anrop där varje resurs kräver en egen slutpunkt innebär att man måste navigera i grafen en förfrågan i taget, vilket är precis så långsamt som det låter.
Därför började Facebook bygga GraphQL. Netflix och Coursera arbetade samtidigt på sina egna alternativ. Efter att Facebook gjorde GraphQL till öppen källkod lade Coursera ner sina egna projekt och anammade den nya tekniken. Netflix fortsatte sitt arbete och släppte senare Falcor, ett JavaScript-bibliotek som modellerar fjärrdata som en virtuell JSON-graf. Falcor är numera i stort sett inaktivt, så betrakta det som en historisk fotnot snarare än ett aktuellt alternativ.
GraphQL erbjuder ett frågespråk som låter klienter begära exakt den data de behöver. REST förlitar sig på fasta slutpunkter och serverdefinierade datastrukturer. Huruvida GraphQL är ”bättre” beror på dina krav och hur mycket flexibilitet ditt projekt behöver: GraphQL vinner när det gäller klientflexibilitet och leveranshastighet för frontend; REST vinner när det gäller cachning, övervakning och operativ mognad. Amazons egen beslutsguide för GraphQL ramar in samma avvägning utifrån den totala ägandekostnaden, vilket är en användbar andra åsikt när du bygger upp affärsnyttan internt.
Låt oss gå igenom ett praktiskt exempel, punkt för punkt.
Föreställ dig att du har en blogg och vill att förstasidan ska visa alla senaste inlägg. Du behöver hämta inläggen, så du skulle förmodligen skriva något i stil med detta:
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 vad händer om du även vill ha med författaren? Tre alternativ:
1. Hämta författarna från en annan resurs:
GET /api/posts
GET /api/authors?ids=1,2
[
{ "id": 1, "name": "João Inez" },
{ "id": 2, "name": "Ana Silva" }
]2. Ändra resursen så att den även returnerar författaren:
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. Skapa en resurs som returnerar inläggen tillsammans med författaren:
GET /api/posts-with-authors
[
{
"id": 1,
"title": "GraphQL vs REST",
"author": { "id": 1, "name": "João Inez" }
}
]Varje alternativ löser problemet men skapar ett nytt. Låt oss ta dem ett i taget.
Med det första tillvägagångssättet, att hämta författarna från en annan resurs, slutar det med två serveranrop istället för ett. Skala upp det och du får fler anrop till fler slutpunkter bara för att sammanställa en enda vy. På en mobiluppkoppling är varje tur-och-retur-resa en latens som användaren känner av direkt.
Med GraphQL händer inte det. Ett anrop, inga extra rundresor:
{
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" }
}
]
}
}Det andra tillvägagångssättet, att ändra resursen så att den även returnerar författaren, löser det omedelbara problemet på ett bra sätt. Sedan skapar det i tysthet ett annat problem någon annanstans i din applikation. Over-fetching.
Tillbaka till din blogg. Den här gången har du även ett sidofält som listar månadens populäraste inlägg med titlar, undertitlar och datum, och det använder /api/posts resurs. Du ändrade resursen så att den nu även returnerar författaren. Sidofältet behöver inte författaren, men alla klienter som anropar slutpunkten får betala för den ändå.
För användare med begränsad datamängd och långsamma anslutningar är onödig data en verklig kostnad. GraphQL låter klienten efterfråga exakt de fält som behövs och inget annat, så problemet uppstå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" }
]
}
}Vilket för oss till den tredje metoden: att skapa en resurs som returnerar inlägg tillsammans med författaren. Att strukturera slutpunkter utifrån vyerna i projektet är ett vanligt mönster.
Det löser visserligen problemet ovan, men det saktar också ner frontend-utvecklingen eftersom varje specifik vy nu kräver en egen specifik slutpunkt. Om en vy behöver ett nytt fält stannar frontend-arbetet av i väntan på att backend-teamet levererar uppdateringen. Den koordineringskostnaden är något som team konsekvent underskattar.
GraphQL ger istället beställningsblocket direkt till klienten. Att lägga till ett fält kräver ingen backend-release. Du går från detta:
{
posts {
title
author {
name
}
}
}Till detta:
{
posts {
title
subtitle
date
author {
name
avatarUrl
}
}
}Det krävs ingen ändring i backend däremellan.
| Dimension | GraphQL | REST |
|---|---|---|
| Datahämtning | Klienten anger fälten; en begäran returnerar exakt dessa | Servern definierar svaret; relaterad data kräver fler anrop |
| Slutpunkter (Endpoints) | En slutpunkt för hela schemat | En slutpunkt per resurs |
| Cachning | Byggs av dig, i klienten eller i ett lager för sparade frågor (persisted queries) | Ingår automatiskt via HTTP; fungerar i webbläsaren och på CDN-nivå |
| Felhantering | 200 OK med en fel-array; kräver verktyg med stöd för GraphQL | HTTP-statuskoder, vilka förstås av alla övervakningsverktyg |
| Auktorisering | Tvingande per fält eller per resolver | Tvingande per slutpunkt |
| Versionshantering | Additiv; gamla fält markeras som @deprecated | Explicit, vanligtvis från /v1/ till /v2/ |
| Hastighetsbegränsning (Rate limiting) | Baserad på frågekostnad och djup, eftersom anropskostnaden varierar | Baserad på anrop per minut, eftersom kostnaden är ungefär densamma |
| Bästa användningsområde | Flera olika klienter som delar på en backend | Offentliga API:er, läsintensiv och cachningsbar trafik |
En snabb sammanfattning av skillnaderna och vad de innebär för dig:
Som sagt ersätter GraphQL inte REST. Om man ser förbi skillnaderna har de två mycket gemensamt, vilket är en anledning till att valet mellan REST och GraphQL sällan är ett antingen-eller:
Query och Mutation -typer fyller samma funktion som listan med slutpunkter i ett REST-API. En mutation är för övrigt helt enkelt en GraphQL-åtgärd som skriver data istället för att läsa den.GraphQL skapades för mobilklienter, och det är fortfarande där tekniken kommer bäst till sin rätt. En mobilapp körs på en anslutning som du inte har kontroll över, så varje onödigt fält och varje extra anrop innebär latens som användaren märker av. Tänk tillbaka på exemplet med överflödig data: sidofältet behövde tre fält, men det modifierade REST-gränssnittet returnerade fem, inklusive ett nästlat författarobjekt som vyn aldrig visade. Multiplicera detta över en hel skärm, på ett dåligt nätverk, så märks det tydligt.
Ju fler klienter du betjänar från en och samma backend, och ju mer de skiljer sig åt, desto viktigare blir detta. Det är också en bra lösning när frontend-utvecklingen går snabbare än backend-utvecklingen, eftersom schemat absorberar förändringar som annars hade krävt nya slutpunkter.
Detta är den arkitektur vi oftast bygger för: ett API med låg latens som betjänar flera klienter från en gemensam backend. På TrustPortal, till exempel, levererade vi både webb- och mobilapplikationen tillsammans med de bakomliggande API-tjänsterna, optimerade för låg latens och byggda för att fungera på många språk för en internationell användarbas. Det är precis i en sådan situation som ett enhetligt, klientanpassat datalager lönar sig, oavsett om du når det via GraphQL eller ett noggrant utformat REST-API.
GraphQL är ett kraftfullt verktyg, men det är inte komplett. Om något av följande är viktigt för ditt projekt bör du överväga REST.
Varje webbläsare har en HTTP-cache som undviker att hämta resurser på nytt och avgör när två resurser är identiska. Det kostar dig ingenting, alla förstår det, och det fungerar lika bra i CDN som i webbläsaren.
GraphQL saknar globalt unika identifierare för objekt på URL-nivå, eftersom alla anrop går till samma slutpunkt, vanligtvis via POST. För att få cachning måste du bygga den själv, antingen i klienten (Apollo Client, Relay, urql) eller i ett lager för beständiga frågor framför servern. Det innebär faktiskt arbete och en ökad operativ komplexitet. Ett REST-API får detta direkt från protokollet och fungerar naturligt tillsammans med en cache som Redis eller Memcached.
Med REST kan du bygga ett övervakningssystem baserat på statuskoder. En 500-kod är en incident, en 404 betyder att en resurs saknas, och en 200 betyder att allt fungerar som det ska. GraphQL ger dig inget av detta, eftersom det returnerar 200 OK för nästan allt, även vid fel. Ett typiskt GraphQL-fel ser ut så här:
{
"errors": [
{
"message": "Cannot query field \"avatarURL\" on type \"Author\".",
"locations": [{ "line": 5, "column": 7 }],
"path": ["posts", 0, "author"]
}
],
"data": null
}Att hantera och övervaka olika felsituationer från ett sådant svar kräver mer arbete, och färdiga lösningar för larm baserade på HTTP-statuskoder kommer inte att upptäcka felet överhuvudtaget. Du behöver GraphQL-specifik instrumentering innan du ens överväger att gå i produktion.
Med GraphQL kan du fråga efter exakt vad du vill när du vill, och den friheten har säkerhetsmässiga konsekvenser. Om en illasinnad aktör skickar en resurskrävande nästlad fråga för att överbelasta din server eller databas, och din server saknar skydd, är du sårbar för överbelastningsattacker (DoS). OWASP GraphQL Cheat Sheet är tydlig med detta: frågedjup och mängd är obegränsade som standard, så du måste själv lägga till begränsningar. En REST-slutpunkt har en begränsad kostnad genom sin konstruktion. En GraphQL-fråga har det inte.
De flesta jämförelser stannar vid överflödig datahämtning. Men det är de operativa skillnaderna som faktiskt avgör resultatet när API:et väl är i drift och någon har jour för det.
Autentisering fungerar i stort sett likadant i båda fallen: en token i en header som valideras för varje anrop. Auktorisering är en annan femma. I REST ligger behörighetskontroller vid slutpunkten, och du kan se vem som får anropa vad genom att läsa routetabellen. I GraphQL kan en fråga korsa flera typer i ett och samma anrop, så behörigheter måste tillämpas per fält eller per resolver. Det innebär mer kod, och det är kod som måste vara heltäckande: ett enda oskyddat fält i en nästlad typ kan läcka den data som slutpunkten ovanför var tänkt att skydda. OWASP rekommenderar att tillämpa auktorisering på både noder och kanter just för att det är så lätt att lämna den luckan öppen.
Hastighetsbegränsning baserad på antal anrop per minut fungerar för REST, där anropen kostar ungefär lika mycket. Det fungerar inte för GraphQL, där ett anrop kan vara trivialt medan nästa kan koppla samman halva databasen. GraphQL-API:er behöver begränsningar för frågedjup, komplexitetsberäkning som tilldelar en kostnad till varje fält, och ofta persisterade frågor, som endast tillåter en förhandsgodkänd uppsättning operationer i produktion. Budgetera för det arbetet nu, istället för att upptäcka behovet under en incident.
REST versionshanteras via URL, /v1/ till /v2/, vilket är tydligt, enkelt att kommunicera och innebär att du underhåller båda. GraphQL kringgår versionshantering: du lägger till fält och markerar gamla som föråldrade med direktivet @deprecated , och klienterna migrerar i sin egen takt. Detta är genuint användbart för ett schema som betjänar många klienter, med en förpliktelse: följ upp fältanvändning, annars kommer de föråldrade fälten aldrig att tas bort och schemat kommer att växa i all oändlighet.
Eftersom en GraphQL-resolver körs per fält kan en sökning efter 50 inlägg med tillhörande författare utlösa 51 databasfrågor: en för inläggen och en per författare. Detta är det N+1-problemet, och det är den absolut vanligaste anledningen till att ett sprillans nytt GraphQL-API visar sig vara långsammare än det REST-API det ersatte. Lösningen är batchning, det vill säga att samla ihop de 50 författarsökningarna till ett enda databasanrop, vanligtvis med DataLoader eller ett motsvarande bibliotek. Det är inget valfritt vid någon form av verklig belastning. REST slipper inte heller undan N+1, men eftersom frågemönstret bakom en slutpunkt är fast, upptäcks det under utvecklingsfasen istället för under belastning i produktion.
En sak har förändrat förutsättningarna för detta beslut sedan GraphQLs tidiga dagar: man bygger numera sällan en monolitisk graf. Federation gör det möjligt för flera team att var för sig äga en subgraf, som en gateway sedan sammanställer till en enhetlig graf som klienten frågar efter som om det vore ett enda API. Om din organisation är så pass stor att "GraphQL vs REST" i själva verket handlar om "hur många team kan exponera ett sammanhängande API", är detta mönstret att överväga.
Ekosystemet håller på att standardiseras även här. GraphQL Foundations arbete med Composite Schema Specification syftar till att göra grafer med flera tjänster portabla mellan olika gateways, istället för att de är låsta till en specifik leverantörs implementation. Det är värt att nämna i varje jämförelse under 2026, eftersom det förändrar den operativa kalkylen: federation lägger till ett lager för sammansättning och gateway som måste förvaltas, utöver allt som nämndes i avsnittet ovan.
REST har ingen direkt motsvarighet. Det närmaste alternativet är en API-gateway som kopplar samman flera tjänster, men utan ett delat typsystem mellan dem. Om målet är en enhetlig, starkt typad graf över många team, är det en fördel för GraphQL. Om varje tjänst kan stå för sig själv bakom sina egna slutpunkter, håller REST saker och ting enklare.
GraphQL vs REST är inte hela bilden. gRPC är ett starkt alternativ för intern trafik mellan tjänster, där ett binärt protokoll och genererade klienter överträffar läsbar JSON när ingen anropar dig från en webbläsare. tRPC är värt att titta närmare på när båda ändarna av stacken är TypeScript i en och samma kodbas, eftersom det ger dig typ-säkerhet från ände till ände utan ett schema-språk eller ett steg för kodgenerering. Det fungerar dock inte för en klient du inte själv äger.
Den grova uppdelningen: REST för publika och tredjeparts-API:er, GraphQL för varierade förstaparts-klienter, gRPC för intern trafik mellan tjänster, tRPC för fullstack-produkter i TypeScript. Stora miljöer kör mer än en av dessa. Det är ett normalt slutläge, inte ett misslyckande att standardisera.
Två funktioner saknar motsvarighet i REST, och båda förändrar hur team arbetar snarare än hur API:et presterar.
GraphQL använder sitt eget typsystem för att definiera ett API:s schema, med en syntax som kallas Schema Definition Language (SDL). Schemat är ett kontrakt mellan server och klient som fastställer hur en klient kan komma åt datan.
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 schemat väl finns på plats kan frontend- och backend-team arbeta oberoende av varandra, eftersom frontenden kan testas mot simulerad data som genererats utifrån det. Frontenden kan också läsa schemats typer, frågor och mutationer genom introspection, den inbyggda förmågan att fråga schemat självt och få tillbaka en lista över tillgängliga typer och fält. Du får dessutom typsäkerhet på köpet, vilket fångar upp typfel tidigt på båda sidor. Specifikationen från september 2025 introducerade Schema Coordinates, vilket gör att det introspekterade schemat kan adresseras på ett standardiserat sätt – något som är praktiskt för kodgenerering, register och AI-verktyg.
GraphQL-IDE:n är en av de mest användbara delarna i verktygskedjan. Den drar nytta av schemats självbeskrivande natur och eliminerar det mesta av gissningsarbetet vid integrationsarbete.
Använd en aktuell och underhållen klient som GraphiQL (som underhålls av GraphQL Foundation), Apollo Sandbox eller Altair för att inspektera ditt schema och köra frågor och mutationer mot ditt API utan att först behöva skriva en klient.
En notering om verktygens aktualitet: den äldre GraphQL Playground har pensionerats och tagits bort från Apollo Server 3. Den har inte underhållits sedan 2019 och har kända säkerhetssårbarheter, så välj GraphiQL, Apollo Sandbox eller Altair för alla nya projekt.
Den tekniska jämförelsen avgör sällan detta på egen hand. Det som avgör är leveranshastighet, driftskostnad och den risk du tar på dig.
Detta är checklistan våra ingenjörer använder vid API-kartläggning, innan en enda rad kod skrivs. Besvara alla fem. Om tre eller fler pekar åt samma håll är det en tydlig signal.
Svara ärligt på dessa frågor så är beslutet oftast redan fattat. Det mönster vi ser oftast i mobilprodukter är ett GraphQL-lager framför befintliga REST-tjänster, som införs en klient i taget istället för genom en total övergång.
GraphQL ger dig en flexibel och deklarativ utvecklingsmiljö och löser faktiska problem som REST lämnar över till klienten. Det har en stor community, ett moget ekosystem och implementationer i flera populära språk, däribland JavaScript, Go och Java. Det här inlägget går igenom det som är viktigt för att kunna fatta ett beslut. GraphQL-specifikationen går betydligt djupare in på själva språket.
Bygger du ett API främst för en mobilapplikation? GraphQL är ett rimligt förstahandsval, eftersom bandbredd och antal anrop är vad dina användare märker av. Behöver du edge-caching, mogen övervakning och förutsägbara kostnader för anrop? REST är fortfarande det bättre standardvalet.
Så är GraphQL slutet för REST? Nej, självklart inte. Det är inte en perfekt teknik och den har nackdelar som REST saknar. Om man kokar ner hela jämförelsen till en enda mening blir det: GraphQL kontra REST handlar om dina klienter, ditt team och din drift, aldrig om vilken teknik som ser modernast ut.
Nej. GraphQL växer i popularitet, men REST är fortfarande standard för publika och externa API:er, och de flesta organisationer använder båda. GraphQL läggs oftast till framför befintliga REST-tjänster snarare än att ersätta dem.
För en klient som behöver data från flera resurser, ja, eftersom en förfrågan ersätter flera anrop och nyttolasten inte innehåller några oanvända fält. För en enskild cachebar resurs är REST oftast snabbare, eftersom en HTTP-cache eller ett CDN kan leverera den utan att ens kontakta din server. Ett GraphQL-API utan batchning som drabbas av N+1-problemet kan vara betydligt långsammare än det REST-API det ersatte.
När trafiken är lästung och levereras via ett CDN, när du har en klient med en stabil datamodell, när din övervakning bygger på HTTP-statuskoder, eller när teamet som underhåller API:et är litet och redan har hög arbetsbelastning.
Ja, och det är det vanligaste mönstret. Ett GraphQL-lager placeras framför befintliga REST-tjänster och löser fält genom att anropa dem, vilket gör att du kan migrera en klient i taget istället för att genomföra ett totalt byte.
Servern är den mindre delen. Schemadesign, auktorisering på fältnivå, batchning, cachning och migrering på klientsidan är där det mesta arbetet ligger, och arbetet är inte klart förrän de gamla slutpunkterna har avvecklats. Avgränsa arbetet per klient istället för att se det som ett enda stort projekt.
Ingetdera är i grunden säkrare, men de har olika sårbarheter. REST har en begränsad kostnad per slutpunkt och behörighetskontroller på ett ställe. GraphQL kräver auktorisering på fältnivå, begränsningar för frågedjup och komplexitet, samt oftast persistenta frågor, eftersom en enskild fråga kan vara godtyckligt dyr och kan nå typer som anroparen inte borde ha tillgång till. OWASP GraphQL Cheat Sheet är standardreferensen för att säkra upp detta.
Federation gör att flera team kan äga varsin delgraf (subgraph), som en gateway sedan sammanställer till en enhetlig graf som klienten frågar efter som ett enda API. Composite Schema Specification standardiserar hur dessa grafer sammanställs över olika gateways. Det passar stora organisationer som exponerar ett sammanhängande API från många tjänster, till priset av att behöva drifta ett lager för komposition och gateway.
Den nuvarande stabila utgåvan av GraphQL-specifikationen är September 2025 edition, den första fullständiga utgåvan sedan oktober 2021. Den lade till Schema Coordinates, OneOf-inputobjekt och beskrivningar för körbara dokument, varav flera är riktade mot kodgenereringsverktyg samt LLM- eller agentverktyg.
Väljer du mellan GraphQL och REST för en produkt du bygger? Vi designar och bygger API:er för webb- och mobilprodukter, från plattformar med låg latens som TrustPortal till konsumentprodukter med hög volym som Game Achievements. Vi diskuterar gärna avvägningarna utifrån era klienter, ert team och er roadmap innan ni bestämmer er för något av alternativen. Kontakta vårt team.
Webbutvecklare, brukar skriva null istället för nil. Älskar att utforska den funktionella stilen i Javascript.
People who read this post, also found these interesting:
