REST vs GraphQL vs SPARQL

In de huidige stand van de techniek wordt met API meestal een REST API bedoeld, hoewel er vele varianten van API's bestaan. Een REST API staat voor een API die gebruik maakt van internet protocollen als TCP/IP en HTTP voor het bevragen. Er zijn echter ook andere API standaarden die gebaseerd zijn op deze internet protocollen en in opkomst zijn, zoals GraphQL en SPARQL. Het bestaan en de verschillen zijn relevant voor dit onderzoek. Hieronder worden deze verschillen toegelicht.

REST

REST staat voor Representational State Transfer waarmee geduid wordt op een Resource. Met een REST API kan een Resource bevraagd en (eventueel) ook gemuteerd worden en daarbij wordt (dus) gebruik gemaakt van de HTTP methods als GET, PUT en POST. De data wordt in JSON formaat (JavaScript Object Notation) over HTTP uitgewisseld (transport) tussen een client en de server.

REST API’s/RESTful-webservices zijn opgezet om geïsoleerd en enkelvoudige informatie beschikbaar te stellen. Elke API heeft één specifieke input en output. Relaties tussen objecten zijn in de (output) JSON als URL opgenomen welke direct gebruikt kan worden om dan een gerelateerd object op te vragen. Hoewel dit de REST API zeer geschikt maakt voor grote (bulk) en frequente, herhaalde verzoeken, zijn federatieve gegevensverzoeken met behulp van REST API's niet zo eenvoudig. Daarvoor dient een client, de software voor uitvoeren van de bevraging, slim en flexibel te zijn. Tot slot dienen de REST API's te voldoen aan de Restful standaarden, welke de facto standaarden zijn en helaas slechts weinig echt ondersteund worden.

Pros	Cons
Zeer gangbaar Binare autorisatie is gestandardiseerd	Silo gedachte API orkestratie nodig voor samenhang Slechte schema definities onsluiting Geen vrije (schema loze) query mogelijkheden

GraphQL

GraphQL is een query taal (bevragingstaal) voor API's. Het is een nieuwe techniek welke sterk lijkt op een REST API wat betreft het resultaat, namelijk data in JSON formaat. Echter waar REST een reeks endpoints gebruikt per object, gebruikt GraphQL een enkel endpoint/gateway. Wat er opgevraagd kan worden en wat er geretourneerd wordt, is gepubliceerd in een GraphQL schema. Daarbij is het mogelijk om in het bevragen een selectie te maken van welke data je precies nodig hebt. Het is ook mogelijk om meerdere objecten te combineren, zolang dat volgens het schema beschikbaar is. Met een GraphQL gateway is het mogelijk om meerdere schema's en endpoints te bevragen, wat in de richting van een federatieve bevraging komt. GraphQL is daarmee flexibeler dan REST API’s en maakt het mogelijk om integraal informatie beschikbaar te stellen.

Pros	Cons
Minder silo gedachte Mogelijkheden tot samenhang Verfijnde autorisatie mogelijk Gangbaarde/bekender dan SPARQL	Matige schema definities Geen vrije (schema loze) query mogelijkheden Minder gangbaar dan REST

SPARQL

SPARQL (uitspraak 'sparkle') is een standaard query taal en protocol voor Linked (Open) Data op het web en voor RDF triple stores. SPARQL staat voor 'SPARQL Protocol and RDF Query Language' en biedt gebruikers de mogelijkheid om informatie op te vragen van databases of van elke resource die kan worden uitgedrukt in RDF (zie Linked Data). Ook SPARQL is gebaseerd op HTTP net zoals REST en GraphQL en met deze zeer krachtige query taal is het inherent mogelijk om één of meerdere endpoints / API’s in samenhang te bevragen. SPARQL is volledig gebaseerd op Linked Data en de mogelijkheden daarvan.

Pros	Cons
Geen silo gedachtes Hoge samenhang Zeer goede schema definities ontsluiting Schemaloze query mogelijkheden Linked Data zijn W3C Open Standaarden	Verfijnde autorisatie mogelijkheden moeten nog ontwikkeld worden Minder gangbare oplossing onder developers Data moet beschikbaar zijn als Linked Data

Hieronder worden de verschillen tussen de verschillende interfaces gevisualiseerd.

Vergelijking van toegangs mogelijkhede over de drie verschillende application interfaces

Vergelijking API's

GraphQL is een mix tussen REST API’s en SPARQL. Het biedt vergelijkbare functionaliteiten als REST API’s maar met meer mogelijkheden. Waar SPARQL volledig is gebaseerd op Linked Data, voldoet GraphQL slechts ten dele aan (de) Linked Data (principes). Bijvoorbeeld, in een SPARQL endpoint/API kunnen meerdere schema’s gecombineerd worden, terwijl bij GraphQL slecht één expliciet schema van toepassing is.

Vergelijking van vraagkracht van APIs voor federatief bevraging

In het algemeen zijn er drie belangrijke gebruiksscenario's voor linked data via SPARQL endpoints, namelijk; (zoekmachine)vindbaarheid, data-analyse, de semantiek van de data. De belangrijkste use case voor het gebruik en de implementatie van linked data als aanpak is dataverkenning en/of -analyse, waarbij de eis van een semantisch rijke, ondubbelzinnige betekenis voor data vereist is en waar er enig potentieel is voor herbruikbaarheid in andere contexten. SPARQL endpoints bieden ongefilterde toegang tot alles wat beschikbaar is via dat endpoint – de gebruiker is vervolgens vrij om de gegevens op elke gewenste manier op te vragen en indien nodig groeperingen of filters op de gegevens aan te bieden. Deze flexibiliteit en zelfbediening is niet zo aanwezig in GraphQL omdat filters niet zo flexibel kunnen worden toegepast. Een GraphQL endpoint vereist doorgaans enige voorconfiguratie, omdat er al gedefinieerde queries of vragen zijn die de manier bepalen waarop de gebruiker met het endpoint kan communiceren. Bij SPARQL is deze voorconfiguratie niet nodig. In beide gevallen kunnen de prestaties worden opgelost door de manier waarop een query wordt gedefinieerd, en opnieuw betekent het verschil tussen GraphQL- en SPARQL-query's dat deze prestatieverbetering kan worden gedaan binnen de query zelf in SPARQL, en daarom meer door de gebruiker wordt geleid, terwijl dit anders zou zijn. gedaan worden op de backend van een GraphQL endpoint.