TL; DR-version

I ett av de tidigare inläggen diskuterade vi kortfattat hur det är att använda GitHub API v3. Den här versionen är utformad för gränssnitt som alla andra REST API. Det finns slutpunkter för varje resurs som du behöver för att komma åt och / eller ändra. Det finns slutpunkter för varje användare, varje organisation, varje arkiv och så vidare. Till exempel har varje användare sin API-slutpunkt på https: // api.github.com / användare / du kan prova att ersätta ditt användarnamn istället för och ange webbadressen i en webbläsare för att se vad API: et svarar på.

GitHub API v4 använder å andra sidan GraphQL där QL står för Query Language. GraphQL är ett nytt sätt att designa dina API: er. Precis som det finns många webbtjänster som erbjuds som REST-API: er, inte bara de som erbjuds av GitHub, det finns många webbtjänster som gör att du kan ansluta till dem via GraphQL.

Den starkaste skillnaden du kommer att märka mellan GraphQL och REST API är att GraphQL kan fungera från en enda API-slutpunkt. I fallet med GitHub API v4 är denna slutpunkt https: // api.github.com / graphql och det är det. Du behöver inte oroa dig för att lägga till långa strängar i slutet av en rot-URI eller ange en frågesträngsparameter för extra information. Du skickar helt enkelt ett JSON-liknande argument till detta API och ber bara om de saker du behöver och du får tillbaka en JSON-nyttolast med exakt samma information som du begärde. Du behöver inte ta itu med att filtrera bort oönskad information eller drabbas av prestandakostnader på grund av stora svar.

Vad är REST API?

Tja, REST står för Representational State Transfer och API står för Application Programming Interface. Ett REST API, eller ett 'RESTful' API, har blivit kärnan i designfilosofin bakom de flesta moderna klient-serverapplikationer. Idén framgår av behovet av att separera olika komponenter i en applikation som klientsidans gränssnitt och serversidan logik.

Så sessionen mellan en klient och en server är vanligtvis statslös. När webbsidan och relaterade skript har laddats kan du fortsätta att interagera med dem och när du utför en åtgärd (som att trycka på en skicka-knapp) skickas en skicka begäran tillsammans med all kontextuell information som webbservern behöver för att behandla den begäran som användarnamn, tokens, etc). Applikationen övergår från ett tillstånd till ett annat men utan ett konstant behov av anslutning mellan klienten och servern.

REST definierar en uppsättning begränsningar mellan klienten och servern, och kommunikationen kan bara ske under dessa begränsningar. Till exempel använder REST over HTTP vanligtvis CRUD-modellen, som står för Create, Read, Update and Delete och HTTP-metoder som POST, GET, PUT och DELETE hjälper dig att utföra dessa operationer och dessa operationer ensam. Gamla intrångstekniker som SQL-injektioner är inte en möjlighet med något som ett noggrant skrivet REST API (även om det är REST är inte ett säkerhetsmedel).

Det hjälper också UI-utvecklare ganska mycket! Eftersom allt du får från en HTTP-förfrågan är typiskt en textström (formaterad som JSON, ibland) kan du enkelt implementera en webbsida för webbläsare eller en app (på ditt föredragna språk) utan att oroa dig för serverns arkitektur. Du läser API-dokumentationen för tjänster som Reddit, Twitter eller Facebook och du kan skriva tillägg för dem eller tredjepartsklienter på det språk du väljer eftersom du är garanterad att API: s beteende fortfarande kommer att vara detsamma.

Omvänt bryr sig inte servern om front-end är skrivet i Go, Ruby eller Python. Oavsett om det är en webbläsare, app eller en CLI. Det "ser" bara begäran och svarar på lämpligt sätt.

Vad är GraphQL?

Som med allt i datorvärlden blev REST API: er större och mer komplexa och samtidigt ville människor implementera och konsumera dem på ett snabbare och enklare sätt. Det är därför Facebook kom med idén om GraphQL och senare öppnade den. QL i GraphQL står för Query Language.

GraphQL tillåter kunder att göra mycket specifika API-förfrågningar istället för att göra rigida API-samtal med fördefinierade parametrar och svar. Det är mycket enklare eftersom servern sedan svarar med exakt de data som du bad om, utan något överskott.

Ta en titt på denna REST-begäran och dess motsvarande svar. Denna begäran är avsedd att bara visa en användares offentliga bio.