GraphQL ja REST verkkokaupan käyttöön (2027)

REST on verkkosivustojen sovellusohjelmointirajapinnan (API) vaihtoehto, joka tarjoaa useita kiinteitä päätepisteitä, joista jokainen palauttaa tietyn muotoisen datajoukon. GraphQL puolestaan on kyselykieli ja API-arkkitehtuuri, joka tarjoaa yhden päätepisteen ja antaa asiakkaan määrittää tarkalleen, mitä tietoja se haluaa yhdellä kyselyllä.

Valinta REST:n ja GraphQL:n välillä vaikuttaa sivustoon monin tavoin, kuten siihen, kuinka paljon dataa järjestelmien välillä liikkuu, kuinka monta pyyntöä sivu tarvitsee ja miten integraatiot muuttuvat ajan myötä. Shopify valitsi API:kseen GraphQL:n lokakuussa 2024. Tätä päätöstä edeltäneen vuoden aikana Shopify kaksinkertaisti GraphQL:n nopeusrajat ja leikkasi yhteyspohjaisten kyselyiden kustannuksia 75 %.

Tässä oppaassa käymme läpi, miten GraphQL ja REST eroavat toisistaan ja mihin käyttötarkoituksiin kukin niistä sopii. Lisäksi tarjoamme päätöksenteon puitteet suuryritysten verkkokauppatiimeille, jotka pohtivat valintaa näiden kahden vaihtoehdon välillä.

REST: perinteinen lähestymistapa

Verkkokaupan API hoitaa tietojen vaihdon järjestelmien välillä. Asiakas lähettää pyynnön palvelimen päätepisteeseen, ja palvelin vastaa pyyntöön datalla.

REST tulee sanoista Representational State Transfer, ja siihen pohjautuvia rajapintoja kutsutaan RESTful-API:ksi tai REST-API:ksi. Ne juontavat juurensa 2000-luvun alkuun, ja niistä tuli verkkopalveluiden standardi, koska ne käyttävät tiedonsiirtoon ja viestintään tavanomaisia HTTP-menetelmiä, joihin kuuluvat esimerkiksi GET, POST, PUT ja DELETE.

REST:llä on selkeitä vahvuuksia, jotka osoittavat, miksi se on edelleen niin laajalti käytössä:

• Ennustettavat päätepisteet: jokaisella resurssilla on oma URL-osoitteensa, joten esimerkiksi /products/123 tarkoittaa aina samaa asiaa.
• Laajat työkalut: jokainen kieli, yhdyskäytävä ja valvontatyökalu ymmärtää REST:iä.
• Tutut HTTP-tilakoodit: 404 tai 429 kertoo asiakkaalle, mitä tapahtui, ilman vastauksen rungon jäsentämistä.
• Natiivi HTTP-välimuistitallennus: jokaisella GET-pyynnöllä on vakaa URL-osoite, joten selaimet, sisällönjakeluverkot (CDN) ja välityspalvelimet voivat tallentaa vastaukset välimuistiin ilman ylimääräistä työtä.

REST toimii edelleen hyvin yksinkertaisissa, resurssimuotoisissa toiminnoissa: nk. webhookeissa, tiedostojen latauksissa, julkisessa Vain luku -muotoisessa datassa ja integraatioissa, joissa kumppanin työkalut odottavat sitä. Postmanin vuoden 2025 State of the API -raportissa todettiin, että 93 % tiimeistä käyttää edelleen REST:iä.

REST:ssä näkyy kuitenkin heikkouksia tietyissä korkeaa suorituskykyä vaativissa tilanteissa. REST-päätepisteet palauttavat kiinteän datajoukon, mikä voi aiheuttaa kaksi toisiinsa liittyvää ongelmaa:

• Ylihaku: päätepiste voi palauttaa koko tuotetietueen, vaikka asiakas tarvitsee vain varastotasot.
• Alihaku: päätepiste ei välttämättä palauta kaikkia asiakkaan tarvitsemia tietoja, joten asiakkaan on kutsuttava useita päätepisteitä voidakseen koostaa yhden näkymän.

Yksittäinen sivu voi kärsiä samanaikaisesti sekä yli- että alihausta.

Kun mobiililaskenta ja pilvilaskenta yleistyivät 2000-luvulla ja 2010-luvun alussa, nämä tehottomat toiminnot alkoivat nousta esiin yhä selvemmin. Lopulta eräs yritys, joka oli valtavan paineen alla yrittäessään parantaa sivuston nopeutta, keksi jotakin uutta.

GraphQL: tehokkaampi vaihtoehto

Facebook alkoi kehittää GraphQL:ää vuonna 2012 natiivimobiilisovellustensa uudistamisen yhteydessä ja julkaisi sen avoimena lähdekoodina vuonna 2015. Linux Foundationin ylläpitämä GraphQL Foundation on ylläpitänyt määritystä vuodesta 2018. Nykyään lúkuisat merkittävät verkkoalustat ympäri maailmaa käyttävät sitä.

GraphQL ratkaisee REST-API:in liittyvät yli- ja alihaun ongelmat ottamalla käyttöön kyselykielen. Asiakas pyytää vain haluamansa datan, ja palvelin palauttaa tarkalleen pyydetyt tiedot – ei enempää eikä vähempää.

Miten GraphQL-skeema toimii

GraphQL-API määritetään skeeman avulla. Skeema määrittää jokaisen järjestelmän tyypin (kuten Product eli tuote, Variant eli versio, Order eli tilaus ja Customer eli asiakas) ja kunkin tyypin tarjoamat kentät. Se määrittää myös tyyppien väliset suhteet, joten kysely voi hakea dataa tilauksen, sen rivikohteiden ja jokaisen tuotteen välillä ilman erillistä pyyntöä.

Skeema tukee kolmea toimintotyyppiä:

• Kyselyt lukevat dataa.
• Mutaatiot luovat, päivittävät tai poistavat sitä.
• Tilaukset lähettävät päivityksiä asiakkaille tietojen muuttuessa.

Skeema on vahvasti tyypitetty, joten GraphQL-palvelin validoi jokaisen pyynnön ennen sen suorittamista ja hylkää pyynnöt kentistä, joita ei ole olemassa.

Skeema on myös tutkittavissa. Asiakas voi pyytää API:a kuvaamaan itsensä, mikä mahdollistaa automaattisen täydennyksen esimerkiksi GraphiQL:ssä. Lisäksi kehitysympäristöt voivat ilmoittaa virheistä jo ennen kyselyn suorittamista.

Tässä verkkokauppaan keskittyvä kyselyesimerkki. Kysely pyytää tuotteen otsikkoa, sen kahta ensimmäistä versiota hintoineen ja varastotietoineen sekä tuotteen esittelykuvan:

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

Vastaus noudattaa kyselyä. Kentät, joita asiakas ei pyytänyt (kuten kuvaukset, tunnisteet tai SEO-metatiedot), eivät poistu palvelimelta. REST:ssä asiakas saa tuotepäätepisteen ennalta määritetyn vastausmuodon ja hänen on tehtävä erilliset kutsut kaikelle datalle, jota vastaus ei sisällä, kuten metakentille.

GraphQL:n suosio kasvoi, koska Facebookin alkuvaiheessa kohtaama ongelma on nykyään yleinen myös monien muidenkin yritysten keskuudessa: niillä on tarve rakentaa monimutkaisia, datapitoisia sovelluksia, jotka ovat myös nopeita ja vakaita. Tämä ongelma on yleinen sekä pienimpien verkkokauppojen että suurten brändien keskuudessa.

Kuusi hyötyä GraphQL:n käytöstä suuryritysten verkkokaupoissa

GraphQL:n ja REST:n väliset erot saattavat vaikuttaa pieniltä, mutta API:t ovat verkkokauppasivuston toiminnan perusta. Talon perustuksen tapaan APIn valinta voi tarjota pitkän aikavälin vakautta tai aiheuttaa rakenteellisia ongelmia verkkokaupan rakentamisen ja ylläpidon aikana. Nämä ongelmat tulevat kaikkein näkyvimmiksi ja merkityksellisimmiksi liiketoiminnan kasvaessa, ja ne näkyvät erityisen selvästi suuryritysten verkkokaupankäynnissä.

Tässä on yhteenveto tärkeimmistä eroista:

GraphQL:n joustavuus tarkoittaa tietenkin myös kompromisseja. Asiakas hallitsee kyselyä, joten yksi huonosti kirjoitettu pyyntö voi olla paljon kalliimpi kuin mikään REST-kutsu. Palvelin tekee myös enemmän työtä; se tarvitsee ratkaisijan kullekin kentälle ja suojautuu sisäkkäisiltä kyselyiltä, jotka aktivoivat monia tietokantahakuja.

GraphQL:n käyttöönsä ottavat suuryritysten tiimit tarvitsevat selkeän ja tiukan hallinnan skeeman suunnittelun ja kyselykäyttäytymisen ympärille. Tämä tarkoittaa kyselykustannusrajoja, syvyysrajoja ja skeeman jaettua omistajuutta. Kirjaa nämä suuryritysohjelmiston vaatimuksiin heti alusta alkaen.

Alla olevissa osioissa kuvataan hyödyt, jotka tekevät GraphQL:stä selkeän vaihtoehdon tehtäviin, joissa se toimii parhaiten: vaihtelevat asiakkaat, yhdistetyt datamallit, useat datalähteet ja suorituskyvystä riippuvaiset ostokokemukset.

1. Soveltuu monimutkaiselle datalle

Suuryritysten verkkokauppadata muodostaa verkoston toisiinsa liittyvistä kokonaisuuksista, mikä voidaan visualisoida kaaviona. Tuotteesta on saatavana eri versioita, ja jokaista versiota varastoidaan useissa sijainneissa. Tilaus viittaa asiakkaisiin, alennuksiin ja toimituksiin. B2B-tilillä on omat hinnastonsa ja maksuehtonsa. REST litistää nämä datarakenteet resurssikohtaisiksi päätepisteiksi. Datamallin kasvaessa kasvaa myös yhden näkymän koostamiseen tarvittavien API-kutsujen määrä. Viive kasvaa kaavion mukana.

GraphQL suunniteltiin tällaisia tietoja varten. Skeema kuvaa suhteet suoraan, joten kysely voi palauttaa tarkalleen näkymän tarvitsemat tiedot yhdessä pyynnössä. Siksi GraphQL on keskeinen osa Shopifyn yhtenäistä datamallia.

Western-vaatteiden jälleenmyyjä Tecovas tarvitsi järjestelmän, joka tarjoaa perustoimintojen ohella vahvat API:t. "Etsin järjestelmiä, jotka ratkaisevat arjen peruspulmat, mutta tarjoavat myös laajennettavuutta, vankan API-valikoiman ja mahdollisuuden räätälöintiin omia liiketoimintaprosessejamme varten", Tecovasin teknologiajohtaja Kevin Harwood kertoo.

Tecovas käyttää Shopify POS -alustaa täysin integroituna varastojärjestelmänä. Myyjät voivat tarkistaa ajantasaiset varastomäärät, kun ostaja pyytää tiettyä tuotetta. Sen räätälöity verkkokauppa on rakennettu Shopify Hydrogenin päälle, joka hakee GraphQL Storefront API:sta tuote-, kokoelma- ja ostoskoritiedot.

2. Vähentynyt tiedonsiirto

REST-päätepisteet palauttavat kiinteän datajoukon, joka voi sisältää enemmän tietoja kuin asiakas tarvitsee (ylihaku). Tarpeettoman suuren datamäärän palauttaminen on tehotonta ja voi aiheuttaa viivettä.

Suuryritysten verkkokaupassa jopa millisekunneilla on vaikutusta. Shopifyn tietojen mukaan konversio laskee tyypillisesti noin 1,5 % jokaista 32 ylimääräistä millisekuntia kohden, jonka verkkokauppa käyttää vuorovaikutukseen reagoimiseen.

GraphQL rajaa datan haun asiakkaan pyytämiin kenttiin. GraphQL-API:a käyttävät järjestelmät voivat pienentää kaistanleveyden käyttöä ja parantaa suorituskykyä vähentämällä tarpeetonta tiedonsiirtoa .

3. Vähemmän edestakaisia yhteyksiä palvelimelle

REST-päätepisteet eivät voi kohdistaa hakua tarkkoihin datapisteisiin, joten yksittäisen näkymän saaminen voi vaatia useita pyyntöjä (alihaku). Jokainen pyyntö vaatii täyden edestakaisen yhteyden palvelimelle.

Tuotesivu tarjoaa tästä hyvän esimerkin. Shopifyn REST Admin API:ssa tuotevastaus saapuu yhtenä kiinteänä kuormana, ja siihen liittyvät tiedot, kuten metakentät, vaativat lisäpyyntöjä. Kattavan tuotenäkymän koostaminen voi siksi vaatia useita päätepistekutsuja, joista jokainen palauttaa kenttiä, joita sivu ei käytä. Sama näkymä vaatii vain yhden GraphQL-kyselyn, joka nimeää vain tarvitsemansa kentät.

Kerro tämä koko tuotevalikoiman synkronoinnin, toiminnanohjausjärjestelmän (ERP) integraation tai varastoa reaaliajassa tarkistavan myyntipistesovelluksen (POS) kesken. Ero on mitattavissa. Vähemmän edestakaisia yhteyksiä tarkoittaa nopeampia latausaikoja ja sujuvampaa käyttäjäkokemusta.

4. Parantunut kehittäjäkokemus

REST on monelle kehittäjälle tuttu pitkän historiansa ansiosta. GraphQL saattaa vaatia kehittäjiltä enemmän perehtymistä alkuvaiheessa, mutta on vaivan arvoista. Skeema on vahvasti tyypitetty ja dokumentoi itsensä. Kehittäjä voi tutkia tuntematonta API:a, täydentää kyselyjä automaattisesti ja havaita virheet ennen kuin mitään suoritetaan. Vahvasti tyypitetty skeema auttaa myös säilyttämään tietojen eheyden ajan myötä.

Suuryritysten tiimien kannattaa varautua seuraaviin tilanteisiin:

• Virheiden käsittely: GraphQL palauttaa HTTP 200:n, vaikka osa kyselystä epäonnistuisi, ja tiedot näkyvät virhetaulukossa. Shopifyn GraphQL Admin API dokumentoi tämän eron selkeästi. Asiakkaiden on tarkastettava vastauksen runko eikä luottaa tilakoodeihin.
• Palvelimen monimutkaisuus: Jokainen kenttä vaatii ratkaisijan. Naiivit ratkaisijat voivat aktivoida yhden tietokantakyselyn luettelon kutakin kohdetta kohden (N+1-ongelma). Erä- ja välimuistikerrokset ratkaisevat tämän ongelman, mutta jonkun on rakennettava ne.
• Hallinta: Asiakkaat kirjoittavat omat kyselynsä, joten API:n omistajan on julkaistava kyselykustannus- tai syvyysrajat. Skeemamuutokset vaativat myös tarkastelun asiaankuuluvien tiimien kesken. Esimerkiksi Shopifyn Admin API rajoittaa nopeutta lasketun kyselykustannuksen mukaan pyyntömäärän sijaan.

5. Helpompi API:n kehittäminen

API:t muuttuvat ajan myötä. REST:ssä vastausmuotoa merkittävästi muokkaava muutos tarkoittaa uuden version (/v2/) tarvetta ja siten siirtymäaikaa kullekin asiakkaalle.

GraphQL on suunniteltu kehittämään skeemaa ilman versionumeroita. Uusia kenttiä voidaan lisätä milloin tahansa. Olemassa oleville asiakkaille ei aiheudu kielteisiä seurauksia muutoksista, koska he saavat vain pyytämänsä kentät. Vanhat kentät merkitään poistamisdirektiivillä, joka palauttaa edelleen dataa mutta varoittaa kehittäjiä asiasta heidän työkaluissaan. Poistetut kentät palauttavat virheen validointivaiheessa ennen kyselyn suorittamista.

Merkittävät muutokset voivat silti olla mahdollisia. Tämän vuoksi Shopify versioi API:nsa edelleen neljännesvuosittain. GraphQL poistaa tarpeen versioida koko API joka kerta yhden kentän muuttuessa.

6. Parantunut suorituskyky

Kaikki edellä kuvatut hyödyt voivat tuntua abstrakteilta, joten miten ne näkyvät todellisessa suorituskyvyssä? Lähes 200 000 julkisesti saatavilla olevan datapisteen perusteella Shopify-kaupat renderöityvät jopa 2,4 kertaa nopeammin ja keskimäärin 1,8 kertaa nopeammin kuin muiden alustojen verkkokaupat.

GraphQL vaikuttaa tietenkin yhtenä tekijänä Shopifyn nopeuteen, mutta se ei ole koko selitys. Sivuston nopeus perustuu myös alustaan, johon kuuluvat globaali isännöinti, CDN-jakelu, selaimen välimuistitallennus, pakkaus ja kuvien optimointi. GraphQL vähentää sivun tarvitsemien datan ja edestakaisten yhteyksien määrää. Alusta päättää, kuinka nopeasti sivun muu sisältö saapuu.

Shopify ja GraphQL

Shopify alkoi käyttää GraphQL:ää, kun Facebook oli julkaissut sen julkisesti. Tuohon aikaan parhaita käytäntöjä oli vähän, ja varhaisena omaksujana Shopify perehtyi GraphQL:ään alusta alkaen. Siitä lähtien GraphQL:stä on tullut paljon suositumpi ja entistä tärkeämpi Shopifyn infrastruktuurille, ja Shopify-verkkokaupat ovat hyötyneet siitä.

Shopify valitsi GraphQL:n ensisijaiseksi API:kseen lokakuussa 2024, ja vähitellen kaikkien Shopify App Storeen lähetettyjen uusien sovellusten oli käytettävä GraphQL:ää. REST Admin API on merkitty vanhentuneeksi, vaikka se toimii edelleen. Uudet alustaominaisuudet julkaistaan ensin GraphQL:ssä, ja jotkut niistä toimivat vain GraphQL:llä, kuten 2 000 tuoteversion ja metakohteiden tuki.

Storefront API käyttää GraphQL:ää, ja Admin API on saatavilla GraphQL:n kautta. Functions, UI-laajennukset, App Bridge ja vastaavat työkalut käyttävät GraphQL:ää pääasiallisena API-rajapintanaan.

Molempien käyttäminen suuryrityksen siirtymävaiheen aikana

Alustan modernisoinnin ei tarvitse tarkoittaa jokaisen integraation siirtämistä kerralla. REST:n ja GraphQL:n rinnakkainen suorittaminen jonkin aikaa voi kannattaa, ja juuri näin Skullcandy lähestyi siirtymäänsä.

Skullcandy siirtyi Shopifyhin 90 päivässä. Se korvasi viisivaiheisen räätälöidyn kassan Shopifyn kassalla ja poisti käytöstä erillisen tuotetietojen hallintajärjestelmän (PIM). Tilausten käsittely toimii REST-API:lla ja webhookeilla. Varaston joukkomuutokset toimivat GraphQL-API:n kautta, joka päivittää satoja varastotietueita yhdellä kutsulla sen sijaan, että tietueet päivitettäisiin yksi kerrallaan. Samat REST- ja GraphQL-rajapinnat pyörittävät uusia sovelluksia.

Shopifyhin siirtymisen jälkeen Skullcandyn tulokset olivat välittömiä. Brändin kotisivun latausaika laski 2,8 sekunnista 0,8 sekuntiin heti julkaisua seuranneena päivänä. Skullcandyn ensimmäinen täysi lomasesonki Shopifyssä toi 45 % liikevaihdon kasvun vuositasolla. Sen suurin tuotelanseeraus sai aikaan 200 % kasvun sivustovierailuissa ilman yhtäkään suorituskykyongelmaa.

Milloin käyttää GraphQL:ää ja milloin REST:iä

Nykyään sekä REST että GraphQL ovat tuotantokäytössä Shopifyssä. Käytännön tarpeet vaikuttavat siihen, kumpaa niistä kannattaa käyttää kussakin työkuormassa.

Valitse GraphQL, kun työhön kuuluu seuraavia tekijöitä:

• Monimutkaiset datamallit: tuotteet, joista on saatavana useita versioita, varastointi useissa sijainneissa, B2B-hinnastot tai yhdessä haettavat metakohteet
• Vaihtelevat asiakkaat: verkko, mobiili, POS ja tekoälyagentit, joista kukin tarvitsee eri siivun samoista tiedoista
• Räätälöidyt verkkokaupat: headless-toteutukset Hydrogenilla tai toisella kehyksellä, joissa sivun nopeus riippuu pyyntöjen minimoinnista
• Pitkäikäiset integraatiot: ERP-, tilaustenhallintajärjestelmä- (OMS) ja PIM-yhteydet, joiden on kehityttävä vuosien ajan rikkoutumatta

REST sopii edelleen, kun:

• toiminto on yksinkertainen yksittäisen resurssin luku tai kirjoitus
• kumppanin työkalut odottavat REST:iä tai integraatio on jo rakennettu ja vakaa
• mukana on webhookeja tai tiedostojen latauksia

Molempien käyttäminen migraation aikana on mahdollista. Olemassa olevat REST-integraatiot voidaan pitää käynnissä ja aloittaa uusi työ GraphQL:ssä. Siirrä ensin kooltaan suurimmat tai monimutkaisimmat integraatiot, joissa hyödyt ovat suurimmat. Suhtaudu siirtojärjestykseen osana laajempaa IT-muutossuunnitelmaa yksittäisen uudelleenkirjoituksen sijaan.

Suuryritysten verkkokaupassa GraphQL on vahvempi valinta tietyissä olosuhteissa. Se on API, jolla Shopify julkaisee uudet ominaisuudet ja API, jonka ympärille Shopifyn omat työkalut on rakennettu.