GraphQL vs. REST for Enterprise Commerce (2027)

REST er en stil for programmeringsgrensesnitt (API) til nettsteder som eksponerer flere faste endepunkter, der hvert returnerer en bestemt dataform. GraphQL er et spørrespråk og en API-arkitektur som eksponerer ett enkelt endepunkt og lar klienten spesifisere nøyaktig hvilke data den ønsker i én spørring.

Valget mellom REST og GraphQL har flere konsekvenser for nettstedet ditt, blant annet hvor mye data som flyttes mellom systemene dine, hvor mange forespørsler en side trenger, og hvordan integrasjonene dine endrer seg over tid. Shopify gjorde GraphQL til sitt definitive API i oktober 2024. I året før denne beslutningen doblet vi hastighetsgrensene for GraphQL og kuttet kostnaden for tilkoblingsbaserte spørringer med 75 %.

Denne veiledningen tar for seg hvordan GraphQL og REST skiller seg fra hverandre, og hvor hver av dem passer best. Den gir også et beslutningsrammeverk for bedriftsteam innen handel som skal velge mellom de to.

REST: Den tradisjonelle tilnærmingen

Et API for netthandel håndterer datautveksling mellom systemer. En klient sender en forespørsel til et endepunkt på en server, og serveren svarer med data.

REST står for Representational State Transfer, og API-er bygget på dette kalles RESTful-API-er eller REST-API-er. De stammer fra tidlig 2000-tall og ble standarden for webtjenester fordi de bruker vanlige HTTP-metoder som GET, POST, PUT og DELETE til å kommunisere og overføre data.

REST har tydelige styrker, som viser hvorfor det fortsatt er så utbredt:

• Forutsigbare endepunkter: Hver ressurs har sin egen URL, så noe som /products/123 alltid betyr det samme.
• Bredt verktøyutvalg: Alle språk, gatewayer og overvåkingsverktøy forstår REST.
• Kjente HTTP-statuskoder: En 404 eller en 429 forteller klienten hva som skjedde uten å analysere selve svaret.
• Innebygd HTTP-caching: Fordi hver GET-forespørsel har en stabil URL, kan nettlesere, innholdsleveringsnettverk (CDN-er) og proxyer mellomlagre svar uten ekstra arbeid.

REST fungerer fortsatt godt for enkle, ressursformede operasjoner: webhooks, filopplastinger, offentlige skrivebeskyttede data og integrasjoner der en partners verktøy forventer det. Postmans rapport «State of the API» fra 2025 fant at 93 % av teamene fortsatt bruker REST.

REST viser imidlertid svakheter i visse ytelseskritiske sammenhenger. REST-endepunkter returnerer et fast sett med data, noe som kan skape to beslektede problemer:

• Overhenting: Endepunktet kan returnere hele produktoppføringen når klienten bare trenger lagerbeholdningen.
• Underhenting: Endepunktet returnerer kanskje ikke alt klienten trenger, så klienten må kalle flere endepunkter for å sette sammen én visning.

En enkelt side kan lide av både overhenting og underhenting samtidig.

Etter hvert som mobil databehandling og skytjenester vokste på 2000-tallet og tidlig 2010-tall, ble disse ineffektivitetene mer merkbare. Til slutt kom et selskap under enormt press for å øke sidehastigheten opp med noe nytt.

GraphQL: Et mer effektivt alternativ

Facebook begynte å utvikle GraphQL i 2012 mens de bygget om sine native mobilapper, og gjorde det til åpen kildekode i 2015. GraphQL Foundation, som driftes av Linux Foundation, har vedlikeholdt spesifikasjonen siden 2018. Det brukes nå av store nettplattformer over hele verden.

GraphQL løser problemene med overhenting og underhenting som fulgte med REST-API-er, ved å innføre et spørrespråk. Klienten ber bare om de dataene den ønsker, og serveren returnerer nøyaktig det som ble forespurt, verken mer eller mindre.

Slik fungerer et GraphQL-skjema

Et GraphQL-API defineres av et skjema. Skjemaet deklarerer hver type i systemet (som Product, Variant, Order og Customer) og feltene hver type eksponerer. Det deklarerer også forholdene mellom dem, slik at en spørring kan hente data på tvers av en ordre, dens ordrelinjer og hvert produkt uten å kreve en egen forespørsel.

Skjemaet støtter tre operasjonstyper:

• Spørringer leser data.
• Mutasjoner oppretter, oppdaterer eller sletter data.
• Abonnementer sender oppdateringer til klienten når data endres.

Fordi skjemaet er sterkt typet, validerer GraphQL-serveren hver forespørsel før den kjøres, og avviser alt som ber om et felt som ikke finnes.

Skjemaet kan også inspiseres. En klient kan be API-et om å beskrive seg selv, noe som er det som driver autofullføring i verktøy som GraphiQL og lar IDE-er flagge feil før en spørring i det hele tatt kjøres.

Her er et eksempel på en handelsrettet spørring. Spørringen ber om et produkts tittel, de to første variantene med pris og lagerbeholdning, og produktets fremhevede bilde:

{ product(handle: "trail-runner") { title featuredImage { url } variants(first: 2) { nodes { title price { amount currencyCode } availableForSale } } } }

Svaret speiler spørringen. Felt klienten ikke ba om (som beskrivelser, tagger eller SEO-metadata) forlater aldri serveren. I REST mottar klienten den forhåndsdefinerte svarformen til produktendepunktet, og må gjøre egne kall for alle data svaret ikke inkluderer, slik som metafelt.

GraphQL ble populært fordi problemet Facebook møtte tidlig er et som mange selskaper nå står overfor: behovet for å bygge komplekse, datarike applikasjoner som samtidig er raske og stabile. Det er et problem som nå deles av både de minste nettbutikkene og de største bedriftsmerkene.

Seks fordeler ved å bruke GraphQL for bedriftshandel

Forskjellene mellom GraphQL og REST kan virke subtile, men API-er er grunnleggende for driften av et handelsnettsted. Som grunnmuren i et hus kan valget av API gi langsiktig stabilitet eller skape strukturelle problemer etter hvert som du bygger og vedlikeholder alt annet. Disse problemene blir mest merkbare og alvorlige i stor skala, og de kommer særlig tydelig frem i bedriftshandel.

Her er et sammendrag av de viktigste forskjellene:

Selvsagt har fleksibiliteten til GraphQL sine avveininger. Fordi klienten styrer spørringen, kan en enkelt dårlig skrevet forespørsel bli langt dyrere enn noe REST-kall. Serveren gjør også mer arbeid; den trenger resolvere for hvert felt og må beskytte seg mot nøstede spørringer som utløser mange databaseoppslag.

Bedriftsteam som tar i bruk GraphQL trenger tydelig og streng styring rundt skjemadesign og spørringsatferd. Det betyr grenser for spørringskostnad, dybdegrenser og delt eierskap til skjemaet. Skriv dette inn i kravene til bedriftsprogramvaren din fra starten av.

Avsnittene nedenfor beskriver fordelene som gjør GraphQL til et sterkt valg der det passer best: varierte klienter, sammenkoblede datamodeller, flere datakilder og ytelsessensitive handleopplevelser.

1. Egnet for komplekse data

Data innen bedriftshandel danner et nettverk av sammenkoblede enheter, som kan visualiseres som en graf. Et produkt har varianter, og hver variant har beholdning på flere steder. En ordre refererer til kunder, rabatter og leveranser. En B2B-konto har sine egne prislister og betalingsvilkår. REST flater ut disse datastrukturene til endepunkter per ressurs. Etter hvert som datamodellen vokser, vokser også antallet API-kall som trengs for å sette sammen én visning. Ventetiden vokser i takt med grafen.

GraphQL ble designet rundt denne typen data. Et skjema beskriver forholdene direkte, slik at en spørring kan returnere nøyaktig de dataene en visning trenger i én forespørsel. Det er derfor GraphQL er en viktig del av Shopifys enhetlige datamodell.

Tecovas, en forhandler av western-klær, trengte et system som tilbød sterke API-er i tillegg til det grunnleggende. «Jeg ser etter systemer som løser de helt grunnleggende problemene for meg, men som også tilbyr utvidbarhet, et robust sett med API-er og muligheten til å tilpasse til våre spesifikke forretningsprosesser», sier Kevin Harwood, teknisk direktør i Tecovas.

Tecovas bruker Shopify POS som et fullt integrert lagersystem. Ansatte kan sjekke oppdatert lagerbeholdning når en kunde spør etter en bestemt vare. Den tilpassede nettbutikken deres er bygget på Shopify Hydrogen, som spør mot GraphQL Storefront API etter produkt-, kolleksjons- og handlekurvdata.

2. Redusert dataoverføring

REST-endepunkter returnerer et fast datasett, som kan være mer enn klienten trenger (overhenting). Å returnere mer data enn nødvendig er ineffektivt og kan skape ventetid.

I bedriftshandel har selv millisekunder betydning. For hvert 32. millisekund tregere en butikk svarer på interaksjoner, har konverteringen en tendens til å falle med rundt 1,5 %.

GraphQL begrenser datahenting til feltene klienten ber om. Ved å kutte unødvendig dataoverføring kan systemer som bruker GraphQL-API-er redusere båndbreddebruken og forbedre ytelsen.

3. Færre turer frem og tilbake til serveren

Fordi REST-endepunkter ikke kan rette seg mot presise datapunkter, kan en enkelt visning kreve flere forespørsler (underhenting). Hver forespørsel krever en full tur frem og tilbake til serveren.

En produktside er et godt eksempel. I Shopifys REST Admin API kommer et produktsvar som én fast nyttelast, og tilhørende data som metafelt krever ekstra forespørsler. Å sette sammen en komplett produktvisning kan derfor kreve flere endepunktkall, der hvert returnerer felt siden ikke skal bruke. Den samme visningen krever bare én GraphQL-spørring som navngir kun feltene den trenger.

Multipliser dette på tvers av en katalogsynkronisering, en integrasjon med ressursplanlegging (ERP) eller en kassaapp (POS) som sjekker lager i sanntid. Forskjellen er målbar. Færre turer frem og tilbake betyr raskere lastetider og en jevnere brukeropplevelse.

4. Forbedret utvikleropplevelse

REST er kjent for mange utviklere på grunn av sin lange historie. GraphQL krever kanskje mer av dem i starten, men betaler det tilbake i verktøy. Skjemaet er sterkt typet og selvdokumenterende. En utvikler kan utforske et ukjent API, autofullføre spørringer og fange opp feil før noe kjøres. Et sterkt typet skjema bidrar også til å bevare dataintegriteten over tid.

Det finnes nyanser som bedriftsteam bør planlegge for:

• Feilhåndtering: GraphQL returnerer HTTP 200 selv når deler av en spørring mislykkes, med detaljer i en errors-matrise. Shopifys GraphQL Admin API dokumenterer denne forskjellen eksplisitt. Klienter må inspisere selve svaret i stedet for å stole på statuskoder.
• Serverkompleksitet: Hvert felt trenger en resolver. Naive resolvere kan utløse én databasespørring per element i en liste (det såkalte «N+1»-problemet). Lag for batching og caching løser dette, men noen må bygge dem.
• Styring: Klienter skriver sine egne spørringer, så API-eieren må publisere grenser for spørringskostnad eller dybde. Skjemaendringer må også gjennomgås på tvers av relevante team. Shopifys Admin API, for eksempel, setter hastighetsgrenser basert på beregnet spørringskostnad i stedet for antall forespørsler.

5. Enklere API-utvikling

API-er endrer seg over tid. I REST betyr en endring i svarformen som bryter kompatibiliteten en ny versjon (/v2/) og et migrasjonsvindu for hver klient.

GraphQL er designet for å videreutvikle et skjema uten versjonsnumre. Nye felt kan legges til når som helst. Eksisterende klienter påvirkes ikke fordi de bare mottar feltene de ba om. Gamle felt merkes med et utfasingsdirektiv som fortsatt returnerer data, men advarer utviklere i verktøyet deres. Fjernede felt returnerer en feil ved validering, før spørringen kjøres.

Dette gjør ikke endringer som bryter kompatibiliteten umulige. Shopify versjonerer fortsatt sine API-er hvert kvartal av den grunn. Det GraphQL fjerner, er behovet for å versjonere hele API-et hver gang ett felt endres.

6. Bedre ytelse

Alle disse fordelene kan virke abstrakte, så hvordan slår de ut i faktisk ytelse? På tvers av nesten 200 000 offentlig tilgjengelige datapunkter lastes Shopify-butikker opptil 2,4 ganger raskere, og 1,8 ganger raskere i gjennomsnitt, enn butikker på andre plattformer.

Selvsagt er GraphQL ett bidrag til Shopifys hastighet, ikke hele forklaringen. Sidehastighet kommer også fra plattformen: global hosting, CDN-levering, caching i nettleseren, komprimering og bildeoptimalisering. GraphQL reduserer dataene og antallet turer frem og tilbake en side trenger. Plattformen avgjør hvor raskt resten av siden kommer.

Shopify og GraphQL

Shopify begynte å bruke GraphQL da Facebook offentliggjorde det. På den tiden fantes det få beste praksiser, og som tidlige brukere lærte vi GraphQL fra grunnen av. Siden den gang har GraphQL blitt mye mer populært og enda viktigere for Shopifys infrastruktur, og Shopify-nettbutikker har høstet fordelene.

I oktober 2024 kunngjorde vi at GraphQL skulle bli det definitive API-et for Shopify. Fra 1. april 2025 må alle nye apper som sendes inn til Shopify App Store bruke GraphQL. REST Admin API er merket som utdatert, selv om det fortsatt fungerer. Nye plattformfunksjoner lanseres først i GraphQL, og noen er kun tilgjengelige i GraphQL, som støtte for 2000 produktvarianter og metaobjekter.

Storefront API bruker GraphQL, og Admin API er tilgjengelig via GraphQL. Verktøy som Functions, UI-utvidelser og App Bridge bruker GraphQL som sitt primære API-grensesnitt.

Bruke begge under en bedriftsmigrasjon

En modernisering av plattformen trenger ikke å flytte hver integrasjon på én gang. Å kjøre REST og GraphQL side om side i en periode er støttet, og det var slik Skullcandy grep an sin overgang.

Skullcandy migrerte til Shopify på 90 dager. De erstattet en tilpasset betalingsprosess i fem trinn med Shopify Checkout og pensjonerte et frittstående system for produktinformasjonshåndtering (PIM). Ordrebehandlingen kjører på REST-API-er og webhooks. Endringer av beholdning i bulk går gjennom GraphQL-API-et, og oppdaterer hundrevis av beholdningsoppføringer i ett enkelt kall i stedet for én om gangen. De samme REST- og GraphQL-grensesnittene driver nye apper.

Etter overgangen til Shopify kom resultatene til Skullcandy umiddelbart. Lastetiden for forsiden deres falt fra 2,8 sekunder til 0,8 sekunder dagen etter lansering. Skullcandys første fulle julesesong på Shopify ga 45 % inntektsvekst fra år til år. Den største produktlanseringen deres trakk en økning på 200 % i besøk uten ytelsesproblemer.

Når bør du bruke GraphQL fremfor REST

Både REST og GraphQL er i produksjon hos Shopify i dag. Det er en praktisk beslutning å ta rundt hvilken av dem du skal bruke for hver arbeidsmengde.

Velg GraphQL når arbeidet omfatter:

• Komplekse datamodeller: Produkter med mange varianter, beholdning på flere steder, B2B-prislister eller metaobjekter som må hentes sammen
• Varierte klienter: Web, mobil, POS og KI-agenter som hver trenger en annen del av de samme dataene
• Tilpassede nettbutikker: Headless-bygg på Hydrogen eller et annet rammeverk, der sidehastigheten avhenger av å minimere antall forespørsler
• Langvarige integrasjoner: ERP-, ordrehåndteringssystem- (OMS) og PIM-koblinger som må kunne videreutvikles over år uten å bryte sammen

REST passer fortsatt når:

• Operasjonen er en enkel lesing eller skriving av en enkelt ressurs
• En partners verktøy forventer REST, eller integrasjonen allerede er bygget og stabil
• Webhooks eller filopplastinger er involvert

Å bruke begge under migrasjonen er mulig. Du kan holde eksisterende REST-integrasjoner i gang mens nytt arbeid starter i GraphQL. Flytt de integrasjonene med størst volum eller mest kompleksitet først, der gevinstene er størst. Behandle rekkefølgen som en del av en bredere plan for IT-transformasjon i stedet for en engangsomskriving.

For Shopify-bedriftshandel passer GraphQL best under visse omstendigheter. Det er API-et nye funksjoner lanseres på, og det er API-et Shopifys egne verktøy er bygget rundt.