GraphQL vs. REST API: Hva er forskjellen? – IBM-bloggen

Som kanalene gjennom hvilke programvarekomponenter samhandler og data flyter over internett, er API-er livsnerven til moderne webtjenester. API-teknologier som SOAP (en nettjenestemeldingsprotokoll), REST (en arkitektonisk stil) og GraphQL (et programmeringsspråk og verktøy) forenkle programvareutvikling ved å muliggjøre tredjeparts data- og tjenesterintegrasjon. APIer gjør det også mulig for bedrifter å tilby sikre tjenestefunksjoner og datautveksling til ansatte, forretningspartnere og brukere.

Til tross for mange typer APIer, debatter om to store paradigmer har dominert samtalen de siste årene: REST (representativ statsoverføring) og GraphQL. Begge tilbyr en rekke fordeler og brukes derfor til nettverksprosjekter over hele verden. De er imidlertid betydelig forskjellige i hvordan de håndterer datatrafikk. Her dissekerer vi disse forskjellene og diskuterer hvordan bedrifter kan bruke REST og GraphQL APIer for å optimalisere nettverkene sine.

Hva er REST og GraphQL APIer?

En forståelse av REST og GraphQL APIer individuelt er nødvendig for en sammenligning av de to.

REST

REST ble utviklet på begynnelsen av 2000-tallet, og er en strukturert arkitektonisk stil for nettverkstilkoblede hypermediaapplikasjoner, som er designet for å bruke en statsløs, klient/server, hurtigbufferbar kommunikasjonsprotokoll. REST APIer, også kalt RESTful APIer, er driverne for REST-arkitekturer.

REST API-er bruker unike ressursidentifikatorer (URI) for å adressere ressurser. REST APIer fungerer ved at forskjellige endepunkter utfører CRUD-operasjoner («opprett», «les», «oppdater» og «slett») for nettverksressurser. De er avhengige av et forhåndsdefinert dataformat – kalt en medietype eller MIME-type – for å bestemme formen og størrelsen på ressursene de gir til klienter. De vanligste formatene er JSON og XML (og noen ganger HTML eller ren tekst). 

Når klienten ber om en ressurs, behandler serveren spørringen og returnerer alle dataene som er knyttet til den ressursen. Svaret inkluderer HTTP-svarkoder som "200 OK" (for vellykkede REST-forespørsler) og "404 Not Found" (for ressurser som ikke finnes).

GraphQL

GraphQL er et spørringsspråk og API-kjøretid som Facebook utviklet internt i 2012 før det ble åpen kildekode i 2015.

GraphQL er definert av API-skjema skrevet i GraphQL-skjemadefinisjonsspråket. Hvert skjema spesifiserer typene data brukeren kan spørre etter eller endre, og relasjonene mellom typene. En resolver støtter hvert felt i et skjema. Resolveren gir instruksjoner for å gjøre GraphQL-spørringer, mutasjoner og abonnementer til data, og henter data fra databaser, skytjenester og andre kilder. Resolvere gir også dataformatspesifikasjoner og gjør det mulig for systemet å sy sammen data fra ulike kilder.

I motsetning til REST, som vanligvis bruker flere endepunkter for å hente data og utføre nettverksoperasjoner, avslører GraphQL datamodeller ved å bruke et enkelt endepunkt som klienter sender GraphQL-forespørsler gjennom, uavhengig av hva de ber om. API-en får deretter tilgang til ressursegenskaper – og følger referansene mellom ressurser – for å få klienten alle dataene de trenger fra en enkelt spørring til GraphQL-serveren. 

Både GraphQL og REST APIer er ressursbaserte datautvekslinger som bruker HTTP-metoder (som PUT- og GET-forespørsler) som dikterer hvilke operasjoner en klient kan utføre. Imidlertid er det viktige forskjeller mellom dem som forklarer ikke bare spredningen av GraphQL, men også hvorfor RESTful-systemer har en slik utholdenhet.

Forskjeller mellom GraphQL og REST APIer

GraphQL tilbyr et effektivt, mer fleksibelt tillegg til REST; GraphQL APIer blir ofte sett på som en oppgradering fra RESTful-miljøer, spesielt gitt deres evne til å lette samarbeid mellom front-end og back-end team. GraphQL gir et logisk neste trinn i en organisasjons API-reise, og hjelper til med å fikse problemer som ofte oppstår med REST.

Imidlertid var REST lenge standarden for API-arkitekturer, og mange utviklere og arkitekter er fortsatt avhengige av RESTful-konfigurasjoner for å administrere IT-nettverkene sine. Som sådan er det en integrert del av enhver organisasjons IT-styringsstrategi å forstå forskjellene mellom de to. 

REST og GraphQL APIer er forskjellige i hvordan de administrerer:

Datainnhenting

Fordi REST er avhengig av flere endepunkter og tilstandsløse interaksjoner – der hver API-forespørsel behandles som en ny spørring, uavhengig av andre – mottar klienter hver del av data som er knyttet til en ressurs. Hvis en klient bare trenger et delsett av dataene, mottar den fortsatt alle dataene (overhenting). Og hvis klienten trenger data som spenner over flere ressurser, får et RESTful-system ofte klienten til å spørre hver ressurs separat for å kompensere for utilstrekkelig datainnhenting fra den første forespørselen (underhenting). GraphQL API-er bruker et enkelt GraphQL-endepunkt for å gi kundene et presist, omfattende datasvar på én rundtur fra en enkelt forespørsel, og eliminerer problemer med over- og underhenting.

versjons~~POS=TRUNC

I en REST-arkitektur må teamene versjonere APIer for å endre datastrukturer, og forhindre systemfeil og tjenesteforstyrrelser for sluttbrukeren. Med andre ord, utviklere må lage et nytt endepunkt hver gang de gjør endringer, lage flere API-versjoner og potensielt komplisere vedlikehold. GraphQL reduserer behovet for versjonskontroll fordi klienter kan spesifisere sine datakrav i spørringen. Tillegget av nye felt til serveren påvirker ikke klienter uten behov for disse feltene. Omvendt, hvis felt er avviklet, kan klienter fortsette å be om dem til søk er oppdatert.

Feilhåndtering

REST APIer bør bruk HTTP-statuskoder for å indikere status eller suksess for en forespørsel, og hver statuskode har en bestemt betydning. En vellykket HTTP-forespørsel returnerer en 200-statuskode, mens en klientfeil kan returnere en 400-statuskode og en serverfeil kan returnere en 500-statuskode.

Ved første øyekast virker denne tilnærmingen til statusrapportering mer enkel, men HTTP-statuskoder er ofte mer nyttige for nettbrukere enn for API-ene selv, spesielt i tilfelle feil. REST har ingen spesifikasjon for feil, så API-feil kan vises som transportfeil eller vises ikke med statuskoden i det hele tatt. Denne dynamikken kan tvinge personell til å lese gjennom statusdokumentasjonen for å forstå hva feil betyr eller til og med hvordan feil kommuniseres innenfor infrastrukturen.

Med GraphQL APIer returnerer hver forespørsel – uansett om den resulterte i en feil – en 200 OK-statuskode fordi feil ikke kommuniseres ved hjelp av HTTP-statuskoder (bortsett fra transportfeil). I stedet kommuniserer systemet feil i svarteksten sammen med dataene, så klienter må analysere datanyttelasten for å finne ut om forespørselen var vellykket.

Når det er sagt, har GraphQL en spesifikasjon for feil, så API-feil er lettere å skille fra transportfeil. Den nøyaktige arten av feil vises i "feil"-oppføringen i svarteksten, noe som kan gjøre GraphQL APIer å foretrekke å bygge mot.

Sanntidsdata

REST har ikke innebygd støtte for sanntidsoppdateringer. Hvis en app trenger sanntidsfunksjonalitet, må utviklere vanligvis implementere teknikker som long-polling (der klienten gjentatte ganger poller serveren for nye data) og serversendte hendelser, som kan legge til kompleksitet til applikasjonen.

GraphQL inkluderer imidlertid innebygd støtte for sanntidsoppdateringer gjennom abonnementer. Abonnementer opprettholder en jevn tilkobling til serveren, slik at serveren kan sende oppdateringer til klienten når spesifikke hendelser skjer.

Verktøy og miljø

REST-miljøet er godt etablert, med et bredt spekter av verktøy, biblioteker og rammeverk tilgjengelig for utviklere. Arbeid med REST APIer krever likevel at teamene navigerer gjennom flere endepunkter og forstår de unike konvensjonene og mønstrene til hver API.

GraphQL APIer er relativt nye, men GraphQL-miljøet har vokst enormt siden introduksjonen, med ulike verktøy og biblioteker tilgjengelig for både server- og klientutvikling. Verktøy som GraphiQL og GraphQL Playground gir kraftige, integrerte utviklingsmiljøer i nettleseren (IDE) for å utforske og teste GraphQL APIer. Videre har GraphQL sterk støtte for kodegenerering, noe som kan forenkle utviklingen på klientsiden.

caching

REST APIer er avhengige av mekanismer som eTags og sist endrede overskrifter for å bufre API-anrop. Selv om disse bufringsstrategiene er effektive, kan de være kompliserte å implementere og er kanskje ikke egnet for alle brukstilfeller.

GraphQL APIer kan være mer utfordrende å cache på grunn av den dynamiske naturen til spørringene. Imidlertid kan distribusjon av vedvarende spørringer, svarbufring og hurtigbuffring på serversiden redusere disse utfordringene og strømlinjeforme bredere hurtigbufring i GraphQL-arkitekturer.

Når du skal bruke GraphQL og REST APIer

Verken REST eller GraphQL APIer er iboende overlegne; de er forskjellige verktøy som er egnet for forskjellige oppgaver. 

REST er generelt enklere å implementere og kan være et godt valg når en enkel, bufrbar kommunikasjonsprotokoll med strenge tilgangskontroller er en foretrukket (for offentlige e-handelssider som Shopify og GitHub, som et eksempel). Gitt under- og overhentingsrisikoen, er REST APIer best for:

• Bedrifter som bruker mindre apper med enklere dataprofiler
• Bedrifter uten komplekse krav til dataspørring
• Bedrifter hvor det meste av kundebasen bruker data og drift på lignende måter

GraphQL APIer muliggjør mer fleksibel og effektiv datahenting, noe som kan forbedre systemytelsen og brukervennligheten for utviklere. Disse funksjonene gjør GraphQL spesielt nyttig for å bygge APIer i komplekse miljøer med raskt skiftende frontend-krav. Dette inkluderer:

• Bedrifter med begrenset båndbredde som ønsker å begrense anrop og svar
• Bedrifter som ønsker å kombinere datapunkter på ett endepunkt
• Bedrifter hvis kundeforespørsler varierer betydelig

Selv om de bruker forskjellige tilnærminger, har både GraphQL- og REST-API-er potensial til å forbedre skalerbarheten og serverytelsen betydelig. 

Ta kontroll over API-miljøet ditt med IBM API Connect

Uansett om du velger å distribuere REST eller GraphQL APIer – eller en kombinasjon av de to – kan virksomheten din dra nytte av et bredt spekter av potensielle applikasjoner, inkludert implementeringer i ulike programmeringsspråk (som JavaScript) og integrasjon med microservices og server arkitekturer. Med IBM API Connect, kan du bruke begge API-typer for å optimalisere IT-infrastrukturen din.

IBM API Connect er en API-administrasjonsløsning for hele livssyklusen som hjelper deg med å lage, administrere, sikre, sosialisere og tjene penger på APIer, og fremme digital transformasjon på tvers av datasentre og skymiljøer. Dette betyr at både bedrifter og kunder kan drive digitale apper og stimulere til innovasjon i sanntid.

Med API Connect kan bedrifter bidra til å sikre at de opererer i forkant av API-administrasjon, noe som vil vise seg å være uvurderlig i et databehandlingslandskap som er klar til å vokse seg større, mer komplekst og mer konkurransedyktig over tid.

Utforsk IBM API Connect

Abonner på AI-emneoppdateringer