TL; DR-versjon

I et av de forrige innleggene diskuterte vi kort fortalt hvordan det er å bruke GitHub API v3. Denne versjonen er designet for å være grensesnitt som alle andre REST API. Det er endepunkter for hver ressurs du trenger for å få tilgang til og / eller endre. Det er sluttpunkter for hver bruker, hver organisasjon, hvert depot og så videre. For eksempel har hver bruker sitt API-sluttpunkt på https: // api.github.com / brukere / du kan prøve å erstatte brukernavnet ditt i stedet for og skriv inn URL-en i en nettleser for å se hva API-en reagerer på.

GitHub API v4 bruker derimot GraphQL der QL står for Query Language. GraphQL er en ny måte å designe APIene dine på. Akkurat som det er mange webtjenester som tilbys som REST APIer, ikke bare de som tilbys av GitHub, er det mange webtjenester som lar deg grensesnitt med dem via GraphQL.

Den sterkeste forskjellen du vil merke mellom GraphQL og REST API er at GraphQL kan fungere av et enkelt API-endepunkt. I tilfelle av GitHub API v4 er dette sluttpunktet https: // api.github.com / graphql og det er det. Du trenger ikke å bekymre deg for å legge til lange strenger på slutten av en rot-URI eller oppgi en spørringsstrengparameter for ekstra informasjon. Du sender ganske enkelt et JSON-lignende argument til dette API-et, og ber bare om de tingene du trenger, og du vil få en JSON-nyttelast tilbake med nøyaktig samme informasjon som du ba om. Du trenger ikke å forholde deg til å filtrere ut uønsket informasjon, eller lider av ytelsesomkostninger på grunn av store svar.

Hva er REST API?

Vel, REST står for Representational State Transfer og API står for Application Programming Interface. En REST API, eller en 'RESTful' API, har blitt den viktigste designfilosofien bak de fleste moderne klientserverapplikasjoner. Ideen kommer fra behovet for å adskille ulike komponentene i en applikasjon som klient-side UI og server-side logikk.

Så økten mellom en klient og en server er vanligvis statsløs. Når nettsiden og relaterte skript er lastet inn, kan du fortsette å samhandle med dem, og når du utfører en handling (som å trykke på en send-knapp), sendes en sendeforespørsel sammen med all kontekstuell informasjon som webserveren trenger for å behandle forespørselen ( som brukernavn, tokens osv.). Applikasjonen overgår fra en tilstand til en annen, men uten et konstant behov for forbindelse mellom klienten og serveren.

REST definerer et sett med begrensninger mellom klienten og serveren, og kommunikasjonen kan bare skje under disse begrensningene. For eksempel bruker REST over HTTP vanligvis CRUD-modellen, som står for Create, Read, Update and Delete og HTTP-metoder som POST, GET, PUT og DELETE hjelper deg med å utføre disse operasjonene og disse operasjonene alene. Gamle innbruddsteknikker som SQL-injeksjoner er ikke en mulighet med noe som en tett skrevet REST API (selv om det er REST er ikke et sikkerhetsmiddel).

Det hjelper også UI-utviklere ganske mye! Siden alt du mottar fra en HTTP-forespørsel, er typisk en tekststrøm (formatert som JSON, noen ganger), kan du enkelt implementere en webside for nettlesere eller en app (på ditt foretrukne språk) uten å bekymre deg for serverarkitekturen. Du leser API-dokumentasjonen for tjenester som Reddit, Twitter eller Facebook, og du kan skrive utvidelser for dem eller tredjepartsklienter på det valgte språket, siden du er garantert at API-oppførselen fremdeles vil være den samme.

Omvendt bryr serveren seg ikke om front-enden er skrevet i Go, Ruby eller Python. Enten det er en nettleser, app eller en CLI. Den bare ser forespørselen og svarer riktig.

Hva er GraphQL?

Som med alt i datamaskinverdenen, ble REST APIer større og mer komplekse, og samtidig ønsket folk å implementere og konsumere dem på en raskere og enklere måte. Dette var grunnen til at Facebook kom på ideen om GraphQL, og senere åpnet den. QL i GraphQL står for Query Language.

GraphQL tillater klienter å gjøre veldig spesifikke API-forespørsler, i stedet for å ringe API-anrop med forhåndsdefinerte parametere og svar. Det er mye enklere fordi serveren da svarer med nøyaktig dataene du ba om, uten noe overskudd.

Ta en titt på denne REST-forespørselen og dens tilsvarende svar. Denne forespørselen er ment å vise bare brukerens offentlige biografi.