GraphQL vs. REST API

Har du någonsin arbetat med ett webbapputvecklingsprojekt tidigare? Om så är fallet, så har du kanske redan stött på termen "GraphQL". Men vad betyder det egentligen? Används det i server-sida eller klient-sida konfigurationer? Dessutom, när är GraphQL-integrering att föredra framför andra alternativ? I den här artikeln kommer vi att guida dig genom dessa frågor.

Som en kommunikationskanal för datatransfer mellan mjukvarukomponenter över internet spelar API:er en oumbärlig roll i moderna webbtjänstarkitekturer, och fungerar som syre. API-teknologier som SOAP (en webbtjänstmeddelandeprotokoll), REST (arkitekturstil) och GraphQL (ett frågespråk och verktyg) underlättar mjukvaruutveckling genom att stöda integration och datautbyte mellan olika tjänster, vilket gör utvecklingen mer bekväm och flexibel.

Trots de många typerna av API:er har diskussioner de senaste åren huvudsakligen kretsat kring två huvudparadigmer: REST (representational state transfer) och GraphQL. Båda erbjuder en rad fördelar och används globalt i webprojekt. Däremot skiljer de sig avsevärt i hur de hanterar datakommunikation.

Vad är REST API?#

REST är en strukturerad arkitekturstil utvecklad i början av 2000-talet för att bygga hypermedieapplikationer över nätverk, utformad för att anta ett tillståndslöst, cachebart kommunikationsprotokoll mellan klienter och servrar. REST API (även känt som RESTful API) är drivkraften bakom REST-arkitekturen.

REST API använder Uniform Resource Identifiers (URIs) för att adressera resurser. REST API fungerar genom att använda olika ändpunkter för att utföra CRUD (create, read, update och delete) operationer på nätverksresurser. Det förlitar sig på fördefinierade dataformat (kända som mediatyper eller MIME-typer) för att bestämma formen och storleken på de resurser de tillhandahåller till klienter. De vanligaste formaten är JSON och XML (ibland HTML eller ren text).

Efter att klienten begär en resurs, bearbetar servern frågan och returnerar all data relaterad till den resursen. Svaret innehåller HTTP-responskoder som "200 OK" (för en lyckad REST-förfrågan) och "404 Not Found" (för en icke-existerande resurs).

Hur fungerar REST API?#

REST API:er förlitar sig på fördefinierade ändpunkter som exponerar resurser över HTTP. Varje ändpunkt representerar en resurs, såsom användare eller inlägg, och identifieras av en unik URL. REST-operationer är bundna till standard HTTP-metoder som GET, POST, PUT och DELETE, vilket motsvarar att hämta, skapa, uppdatera och radera data.

Till exempel, en förfrågan till GET /users hämtar en komplett lista över användare, medan GET /users/123 hämtar detaljerna för en specifik användare identifierad av sitt ID. Om du också behöver åtkomst till relaterad data, såsom användarens organisationer och organisationsroller, skulle du behöva göra ytterligare anrop till GET /users/123/organizations.

REST följer en resurscentrerad metod och fokuserar på att åtkomstera och manipulera diskreta resurser.

Vad är GraphQL?#

GraphQL är både en API-typ (eller frågespråk) och en runtime-motor för att svara på dessa frågor. Det erbjuder ett förenklat API och är särskilt lämpligt för mobilapplikationer och implementering av komplexa arkitekturer som kräver specifika delmängder av data.

Med GraphQL kan utvecklare specificera den data de vill hämta från API:t. Det tillåter också datainhämtning på begäran istället för att hämta allt på en gång, tillämpar ändringar omedelbart och integrerar tredje parts datakällor i applikationen.

Applikationer kan använda GraphQL-frågor för att anropa GraphQL-tjänster. Dessa frågor returnerar de exakta dataelementen som kunden begär. Detta sparar flera API-anrop, nätverksbandbredd och efterbearbetning. Det är en mycket effektiv lösning för datacentrerade API:er som är belägna nära konsumentenheter såsom surfplattor och mobiltelefoner.

Hur fungerar GraphQL?#

GraphQL, i motsats, tar ett frågebaserat tillvägagångssätt. Istället för fördefinierade ändpunkter exponerar GraphQL en enda ändpunkt som accepterar strukturerade frågor. Klienter specificerar exakt vilken data de behöver med hjälp av ett frågespråk.

Därför måste en komplett GraphQL-implementering ha två delar: schema och resolvers.

GraphQL-schema#

Scheman definierar typerna av data och deras fält som kan hämtas genom GraphQL-frågor:

Till exempel, anta att du har följande schema:

En klient kan fråga efter en användares namn, e-post, organisationer och roller med följande fråga:

Denna fråga hämtar inte bara de begärda fälten (e-post och organisationer) utan också den relaterade datan (roller) i en enda förfrågan.

GraphQL-resolver#

En GraphQL-resolver är en nyckelkomponent i en GraphQL-server som bestämmer hur man hämtar eller beräknar datan som begärs av en klient i en GraphQL-fråga. När en klient skickar en fråga matchas varje fält i frågan till en resolver, som innehåller logiken för att hämta eller beräkna data för det fältet.

I exemplet ovan skulle resolverna för schemat se ut så här:

Det finns två typer av resolvers: rotresolvers och fältresolvers.

• Rotresolvers: Hanterar top-nivåfält i schemat, såsom Query, Mutation och Subscription.
• Fältresolvers: Hanterar individuella fält inom en typ, ofta för nästlade frågor. Om ingen specifik resolver finns för ett fält använder GraphQL standardresolvers, som returnerar värdet från moderobjektet med matchande fältnamn.

GraphQL-operationer#

GraphQL stöder tre typer av operationer: queries, mutations och subscriptions.

• Query: Används för att LÄSA data.
• Mutation: Används för att SKRIVA data, inklusive operationer för att lägga till, ändra och radera data.
• Subscription: Används för att begära en beständig anslutning för data, vilket möjliggör för klienten att deklarera de typer av händelser den är intresserad av och de data som ska returneras.

Skillnader mellan GraphQL och REST API:er#

GraphQL och REST API:er är verktyg för datautbyte mellan olika webbtjänster, men på grund av deras olika tillvägagångssätt för att lösa problem finns här de viktigaste skillnaderna mellan dem:

Datahämtning#

REST API överhämtar eller underhämtar ofta data eftersom ändpunkter returnerar fasta svar. GraphQL löser detta genom att låta klienter begära exakt det de behöver, vilket minskar onödig datatransfer. Detta gör GraphQL idealiskt för applikationer med komplexa databehov, såsom mobila eller låg-bandbreddsmiljöer.

Föreställ dig exemplet ovan där du behöver hämta en användares statiska data, organisationer och organisationsroller tilldelade till användaren. Med REST API, skulle du behöva göra flera förfrågningar till olika ändpunkter för att få all data. Men med GraphQL kan du hämta all data i en enda förfrågan.

Flexibilitet#

REST:s ändpunktsbaserade struktur är enkel och fungerar bra för enkla applikationer med standard CRUD-operationer. Detta beror på att REST API:er är utformade för att vara resurscentrerade, där varje ändpunkt representerar en specifik resurs. Den stora begränsningen med detta tillvägagångssätt är att det inte tillåter snabb iteration och förändringar i kundens krav. Vid varje ändring som görs i klienten måste servern uppdateras för att passa de nya kraven, antingen genom att lägga till nya ändpunkter eller uppdatera befintliga. Detta resulterar ofta i många redundanta ändpunkter och komplex API-versionhantering.

GraphQL, å andra sidan, är mer flexibel och tillåter klienter att begära endast den data de behöver. Denna flexibilitet är särskilt användbar när kundkraven förändras ofta, eftersom det eliminerar behovet av att ändra det serversidans API-implementeringen. Klienter kan begära nya fält eller nästlad data utan att kräva ändringar på servern.

Caching#

Även om GraphQL är mer effektiv och flexibel när det gäller datahämtning, har det också några nackdelar. Ett av de största problemen är caching.

REST API har ett moget ekosystem. På grund av dess tillståndslösa och standardiserade natur är det lätt att cacha svar vid både server- och klientnivå. Detta kan avsevärt minska antalet förfrågningar som görs till servern och förbättra prestandan.

På grund av dess flexibilitet är dock många av caching-teknologierna som finns tillgängliga för REST API inte tillämpliga på GraphQL. Det är nödvändigt att hantera caching på klientsidan, baserat på specifika användningsfall, vilket medför extra arbetsbelastning för klientutveckling.

För- och nackdelar#

Slutsats#

Även om GraphQL har fått starkt momentum som en nykomling under de senaste åren, har REST API fortfarande stor betydelse under en lång tid på grund av sin atomära design och strikta natur.

REST och GraphQL tjänar olika behov och utmärker sig i olika scenarier. REST:s enkelhet gör det till ett perfekt val för enkla applikationer och mikrotjänster. GraphQL utmärker sig i scenarier som kräver flexibel och effektiv datahämtning, särskilt i applikationer med olika klienter eller komplexa relationer mellan data. Valet mellan de två beror på ditt projekts specifika krav, teamexpertis och långsiktiga skalbarhetsbehov.