Upptäck varför vi rekommenderar integration via GraphQL framför REST.
På Zonos erbjuder vi två huvudtyper av API:er för integration: GraphQL och REST. Även om REST API:er har funnits längre och kan vara mer bekanta för många, har vi gått över till GraphQL för att möjliggöra mer flexibilitet och snabbare innovation. Även om båda fortfarande stöds förklarar den här guiden varför GraphQL inte bara är framtiden för våra integrationer utan också framtiden för integrationer i allmänhet — och ett kraftfullare verktyg för att möta era behov idag.
GraphQL är ett alternativt sätt att prata med API:er som är mycket väl lämpat för komplexa datastrukturer och för att bygga gränssnitt ovanpå dem. Till skillnad från att behandla data som separata, fristående delar visar GraphQL hur databitar hänger ihop och relaterar till varandra, vilket gör det enkelt att be om och ta emot information.
Tänk på GraphQL som ett frågespråk som låter er prata med API:et som om ni pratade direkt med databasen. Med GraphQL kan ni komma så nära databasen som möjligt, välja exakt vilken data ni vill ha och hur ni får den, vilket ger en stor prestandafördel.
GraphQL skapades av Facebook för att lösa problemet med att skala komplexa datastrukturer. Som ett resultat av deras framgångsrika adoption har fler och fler företag börjat inse fördelarna med att använda GraphQL för sina API:er.
Kan ni redan REST? GraphQL kommer att kännas bekant.
GraphQL API:er är enklare att arbeta med än ni kanske tror. Om ni är vana vid REST API:er är det så här kärnkoncept från REST översätts till GraphQL.
Funktion↕
REST↕
GraphQL↕
Endpoint
Förfrågningar görs till flera endpoints för olika åtgärder
Alla förfrågningar görs till en enda endpoint (t.ex. /graphql)
Datahämtning
Använd GET-metoder på specifika endpoints för att hämta data
Använd queries för att begära exakt den data som behövs, vilket minskar over-fetching eller under-fetching
Datamodifiering/åtgärder
Använd HTTP-metoder som POST, PUT, PATCH eller DELETE för att ändra eller bearbeta data.
Använd mutations för att utföra operationer (t.ex. skapa parties, beräkna landed costs)
Svarsformat
Fasta svarsformat returnerar alla fördefinierade fält, oavsett om de behövs
Flexibla svar gör det möjligt att specificera exakt vilka fält som ska inkluderas, vilket minskar onödig dataöverföring (Om den här flexibiliteten känns komplicerad kan ni helt enkelt använda de förskrivna query-exempel i vår dokumentation för en RESTful upplevelse)
Datakoppling
Flera förfrågningar krävs ofta för att hämta relaterad data
Nästlade queries möjliggör hämtning av relaterad data i en enda förfrågan (t.ex. party-uppgifter och försändelseartiklar tillsammans). Användare kan också bygga workflows för att hantera flera mutations inom en enda GraphQL-förfrågan, vilket minskar komplexitet och förbättrar effektivitet
Fördelar med GraphQL
Snabbare svar
GraphQL ger snabbare svar genom precis datahämtning, användning av en enda endpoint och förbättrade möjligheter för batchning och caching.
En vanlig utmaning med REST är over-fetching eller under-fetching av data — antingen få för mycket onödig information eller inte tillräckligt av det som behövs på en gång. GraphQL eliminerar detta genom att tillåta förfrågningar om exakt det som behövs — varken mer eller mindre. Den specificiteten förbättrar inte bara prestandan utan förenklar också processen för dem som interagerar med API:et, vilket gör systemet mer effektivt och användarvänligt.
Exempel på hur detta är användbart:
Det låter frontendutvecklare hämta exakt den data de behöver för sina UI-komponenter, vilket minskar antalet round trips till servern och förbättrar prestandan.
Föreställ er att ni vill få en HS-kodklassificering, kartongisering, fraktprissättning och landed cost-offert på artiklar i en checkout. Om ni är integrerade via GraphQL API kan ni göra ett enda anrop med nödvändiga workflows för att få allt ni behöver (och inget ni inte behöver) i ett enda svar. Däremot skulle ni med REST API:er först behöva anropa Classify REST API, sedan anropa Rating REST API separat efteråt, och slutligen koppla in den klassificeringen och fraktprissättningen i ert tredje anrop till Landed Cost REST API. Alla dessa REST API:er skulle returnera varje informationsbit de kan, vilket tvingar er att gå igenom svaret efter den data ni behöver. Den här tidsbesparingen gör skillnad när ni ska returnera en komplett landed cost snabbt, innan shopparen lämnar.
GraphQL API:er har vanligtvis en enda endpoint, till skillnad från REST API:er som ofta har flera endpoints för olika resurser och åtgärder. Det gör det enklare att hantera och förstå API:et.
GraphQL:s förmåga att batcha queries och stöd för cachingstrategier leder till betydande prestandaförbättringar. Dessa funktioner minskar belastningen på nätverk och servrar, vilket ger snabbare och mer tillförlitliga interaktioner för användarna.
Väldefinierade scheman
GraphQL API:er bygger på ett starkt typat schema. Det här schemat definierar strukturen för tillgänglig data och de operationer som kan utföras. Det ger tydlighet kring vilken data som finns tillgänglig och hur den nås, vilket kan förbättra utvecklarproduktiviteten och minska fel. Till exempel kan frontendteam utforska grafen för att få exakt det de behöver istället för att vänta på en ny REST-endpoint.
Möjlighet att förbättra utan att bryta befintliga klienter
Att lägga till nya funktioner eller ändra befintliga i GraphQL stör inte nuvarande integrationer, tack vare den flexibla query-strukturen. Den förmågan säkerställer att förbättringar kan göras utan att bryta kompatibiliteten med befintliga klienter.
Uppdaterad dokumentation
Tack vare GraphQL:s introspection-funktion genereras dokumentationen automatiskt och uppdateras vid varje ändring. Det säkerställer att all information som ges till utvecklare är aktuell, vilket minskar integrationsproblem och supportärenden relaterade till föråldrad dokumentation — en utmaning som ofta ses med REST API-dokumentation.
Föreställ er att ni är på en restaurang med en meny som låter er beställa rätter precis som ni vill ha dem, jämfört med en annan restaurang där ni bara kan välja bland fasta menyer. GraphQL är som den första restaurangen:
Få exakt det ni vill ha: Med GraphQL kan ni be om exakt den data ni behöver — varken mer eller mindre. Föreställ er att ni bara vill ha namnet och priset på en rätt, inte hela ingredienslistan. Med REST API:er måste ni hämta hela rättdetaljerna och ignorera delarna ni inte behöver.
Komponera en skräddarsydd rätt: Vårt GraphQL API kan enkelt kombineras för att skapa mer skräddarsydda lösningar, likt en bufférestaurang där ni kan skapa en unik rätt precis som ni behöver den, med ingredienser de redan har. Däremot är ett REST API som ett bageri med färdiga varor packade i korgar — ni kan bara beställa det som redan har skapats och ni kan inte välja att bara ta hem den bit ni vill ha.
Mindre väntan: Eftersom ni kan få all information ni behöver i en enda förfrågan är det som att be servern ta fram förrätt, huvudrätt och dessert på en gång, snarare än att vänta mellan rätterna. De flesta REST API:er kräver att ni skickar flera förfrågningar för att få olika informationsbitar.
Enkelt att ändra beställningar: Om er apps databehov förändras gör GraphQL det enklare att justera. Ni ändrar bara queryn för det ni behöver. Med REST kan ni behöva vänta på att köket (backend) skapar en ny rätt (endpoint) till menyn, vilket tar mer tid.
GraphQL erbjuder mer flexibilitet, effektivitet och enkelhet för att hämta data än REST API:er, särskilt när era behov förändras eller växer.
Under moderniseringen av vår plattform de senaste åren har Zonos valt att bygga ny funktionalitet med GraphQL för vårt API istället för REST. Vi beslutade detta eftersom vår data är komplex och sammanlänkad, ungefär som den data som ledde Facebook till att skapa GraphQL. Den komplexiteten gör det utmanande att bygga skalbara REST API:er eftersom sätten utvecklare behöver hämta och använda data varierar dramatiskt mellan implementationer, och REST är inte flexibelt.
GraphQL löser snyggt det här problemet genom att låta utvecklare som implementerar vårt API välja exakt vilken data de vill ha och hur de får den. Det låter dem passa in den i sina workflows utan att Zonos behöver göra skräddarsytt arbete (medan de väntar) för varje situation.
Det kombinerade resultatet av att använda GraphQL och moderniseringarna i vår plattform har gjort vårt API mer högpresterande, gjort det snabbare att integrera Zonos i era system och gjort det möjligt för Zonos att leverera nya funktioner snabbare.
Bättre funktioner
Zonos utvecklar kontinuerligt nya funktioner, och GraphQL är den första (och vanligtvis enda) som får dessa uppdateringar. Däremot anses våra REST API:er vara end-of-life och kan inte få tillgång till många av våra nya funktioner.
Exempel på funktioner begränsade till GraphQL:
Inclusive pricing
Labels API
Ny Checkout och Hello
Boxstorlekar i API-svar
Dashboard-rapportering
Möjlighet att begära en DDP-offert om möjligt, men fortfarande returnera en DDU-offert om DDP inte är tillgängligt till det landet med den servicenivån
Detaljerad uppdelning av tullar, skatter och avgifter (artikelinformation, specifika avgifter) — Dashboard drivs av GraphQL och visar den här datan för alla butiker, men REST API-svaret inkluderar inte den här detaljnivån
Varför GraphQL
Varför GraphQL
Upptäck varför vi rekommenderar integration via GraphQL framför REST.
På Zonos erbjuder vi två huvudtyper av API:er för integration: GraphQL och REST. Även om REST API:er har funnits längre och kan vara mer bekanta för många, har vi gått över till GraphQL för att möjliggöra mer flexibilitet och snabbare innovation. Även om båda fortfarande stöds förklarar den här guiden varför GraphQL inte bara är framtiden för våra integrationer utan också framtiden för integrationer i allmänhet — och ett kraftfullare verktyg för att möta era behov idag.
Vad är GraphQL?
GraphQL är ett alternativt sätt att prata med API:er som är mycket väl lämpat för komplexa datastrukturer och för att bygga gränssnitt ovanpå dem. Till skillnad från att behandla data som separata, fristående delar visar GraphQL hur databitar hänger ihop och relaterar till varandra, vilket gör det enkelt att be om och ta emot information.
Tänk på GraphQL som ett frågespråk som låter er prata med API:et som om ni pratade direkt med databasen. Med GraphQL kan ni komma så nära databasen som möjligt, välja exakt vilken data ni vill ha och hur ni får den, vilket ger en stor prestandafördel.
GraphQL skapades av Facebook för att lösa problemet med att skala komplexa datastrukturer. Som ett resultat av deras framgångsrika adoption har fler och fler företag börjat inse fördelarna med att använda GraphQL för sina API:er.
Kan ni redan REST? GraphQL kommer att kännas bekant.
GraphQL API:er är enklare att arbeta med än ni kanske tror. Om ni är vana vid REST API:er är det så här kärnkoncept från REST översätts till GraphQL.
Fördelar med GraphQL
Snabbare svar
GraphQL ger snabbare svar genom precis datahämtning, användning av en enda endpoint och förbättrade möjligheter för batchning och caching.
Precis datahämtning
En vanlig utmaning med REST är over-fetching eller under-fetching av data — antingen få för mycket onödig information eller inte tillräckligt av det som behövs på en gång. GraphQL eliminerar detta genom att tillåta förfrågningar om exakt det som behövs — varken mer eller mindre. Den specificiteten förbättrar inte bara prestandan utan förenklar också processen för dem som interagerar med API:et, vilket gör systemet mer effektivt och användarvänligt.
Exempel på hur detta är användbart:
En enda endpoint
GraphQL API:er har vanligtvis en enda endpoint, till skillnad från REST API:er som ofta har flera endpoints för olika resurser och åtgärder. Det gör det enklare att hantera och förstå API:et.
Batchning och caching
GraphQL:s förmåga att batcha queries och stöd för cachingstrategier leder till betydande prestandaförbättringar. Dessa funktioner minskar belastningen på nätverk och servrar, vilket ger snabbare och mer tillförlitliga interaktioner för användarna.
Väldefinierade scheman
GraphQL API:er bygger på ett starkt typat schema. Det här schemat definierar strukturen för tillgänglig data och de operationer som kan utföras. Det ger tydlighet kring vilken data som finns tillgänglig och hur den nås, vilket kan förbättra utvecklarproduktiviteten och minska fel. Till exempel kan frontendteam utforska grafen för att få exakt det de behöver istället för att vänta på en ny REST-endpoint.
Möjlighet att förbättra utan att bryta befintliga klienter
Att lägga till nya funktioner eller ändra befintliga i GraphQL stör inte nuvarande integrationer, tack vare den flexibla query-strukturen. Den förmågan säkerställer att förbättringar kan göras utan att bryta kompatibiliteten med befintliga klienter.
Uppdaterad dokumentation
Tack vare GraphQL:s introspection-funktion genereras dokumentationen automatiskt och uppdateras vid varje ändring. Det säkerställer att all information som ges till utvecklare är aktuell, vilket minskar integrationsproblem och supportärenden relaterade till föråldrad dokumentation — en utmaning som ofta ses med REST API-dokumentation.
Granska vår GraphQL-dokumentation och vår REST-dokumentation för att se skillnaden.
En analogi
Föreställ er att ni är på en restaurang med en meny som låter er beställa rätter precis som ni vill ha dem, jämfört med en annan restaurang där ni bara kan välja bland fasta menyer. GraphQL är som den första restaurangen:
GraphQL erbjuder mer flexibilitet, effektivitet och enkelhet för att hämta data än REST API:er, särskilt när era behov förändras eller växer.
Hur Zonos använder GraphQL
Under moderniseringen av vår plattform de senaste åren har Zonos valt att bygga ny funktionalitet med GraphQL för vårt API istället för REST. Vi beslutade detta eftersom vår data är komplex och sammanlänkad, ungefär som den data som ledde Facebook till att skapa GraphQL. Den komplexiteten gör det utmanande att bygga skalbara REST API:er eftersom sätten utvecklare behöver hämta och använda data varierar dramatiskt mellan implementationer, och REST är inte flexibelt.
GraphQL löser snyggt det här problemet genom att låta utvecklare som implementerar vårt API välja exakt vilken data de vill ha och hur de får den. Det låter dem passa in den i sina workflows utan att Zonos behöver göra skräddarsytt arbete (medan de väntar) för varje situation.
Det kombinerade resultatet av att använda GraphQL och moderniseringarna i vår plattform har gjort vårt API mer högpresterande, gjort det snabbare att integrera Zonos i era system och gjort det möjligt för Zonos att leverera nya funktioner snabbare.
Bättre funktioner
Zonos utvecklar kontinuerligt nya funktioner, och GraphQL är den första (och vanligtvis enda) som får dessa uppdateringar. Däremot anses våra REST API:er vara end-of-life och kan inte få tillgång till många av våra nya funktioner.
Exempel på funktioner begränsade till GraphQL:
Var den här sidan till hjälp?