© Liashko/Shutterstock.com
Entwickler Magazin
Interview mit Christian Schwendtler

GraphQL: Eine Alternative zu echten REST-Services?

GraphQL ist eine Abfragesprache und wird unter anderem von Facebook, GitHub und Shopify als Alternative zu RESTful Web Services eingesetzt. Doch was ist GraphQL eigentlich und warum wird derzeit so intensiv darüber gesprochen? Im Interview erklärt Christian Schwendtner die Grundlagen beider Ansätze sowie die Unterschiede und Gemeinsamkeiten im Detail.

Christian Schwendtner


GraphQL & Angular – forget (the) REST? Christian Schwendtner: GraphQL ist vorrangig eine flexible Abfragesprache. Das sieht man auch auf der offiziellen Seite graphql.org, wo getitelt wird „A query language for your API“. Das trifft den Kern von GraphQL, denn die clientseitigen Datenbedürfnisse stehen im Vordergrund, die Möglichkeit, auf einfache und flexible Weise die benötigten Daten für Clients abfragen zu können. Ein spannender Punkt ist sicher die Flexibilität, die der Client gewinnt. Er kann einfach und genau definieren, welche Daten (inklusive Relationen) er vom Server benötigt. GraphQL ermöglicht eine sehr client- bzw. Use-Case-orientierte Sicht. Der Client kann mit einem Request genau die Daten laden, die er für einen Use Case bzw. eine Bildschirmmaske benötigt (kein Under- oder Overfetching).EM: Wie unterscheidet sich GraphQL von RESTful Web Services?Schwendtner: Diese Frage bekomme ich sehr oft gestellt, wenn Personen das erste Mal mit GraphQL in Berührung kommen. Bevor man diese Frage beantworten kann, ist es meiner Meinung nach wichtig, den Begriff RESTful Web Services etwas genauer unter die Lupe zu nehmen. Der Begriff ist an sich gut definiert, wird in der Praxis aber oft sehr inflationär verwendet. Wir sagen sehr gern zu jedem Service, der Ressourcen, HTTP-Verben und HTTP-Statuscodes verwendet und Daten in JSON zur Verfügung stellt, REST. Genau genommen stimmt das aber nicht. Von REST oder einem RESTful Web Service dürfte man eigentlich erst dann sprechen, wenn alle Kriterien, die Roy Fielding (der Erfinder von REST) definiert hat, erfüllt sind. Ein wichtiges Kriterium dabei ist HATEOAS, also Hypermedia as the Engine of Application State. Gerade HATEOAS wird aber bei vielen Services, die angeblich RESTful sind, nicht oder nicht ausreichend umgesetzt.Eine gute Möglichkeit, um eine Idee davon zu bekommen, „wie RESTful“ ein Service ist, bietet das Richardson-Maturity-Modell. In ihm sind verschiedene Level definiert, je nachdem, welche Aspekte von REST umgesetzt sind. Ein Service, der nur manche Kriterien von REST erfüllt (z. B. „nur“ Ressourcen, HTTP-Verben, Statuscodes, aber nicht HATEOAS) wird gerne REST-ish, REST-like oder REST-wannabe genannt. Das klingt jetzt vielleicht etwas nach Haarspalterei, aber ich denke es ist wichtig, dass man sich darüber im Klaren ist, was genau man mit GraphQL vergleicht – speziell, wenn es um den Vergleich mit RESTful Web Services geht.Meiner Erfahrung nach kann man sagen, dass GraphQL eine gute Alte...

Entwickler Magazin
Interview mit Christian Schwendtler

GraphQL: Eine Alternative zu echten REST-Services?

GraphQL ist eine Abfragesprache und wird unter anderem von Facebook, GitHub und Shopify als Alternative zu RESTful Web Services eingesetzt. Doch was ist GraphQL eigentlich und warum wird derzeit so intensiv darüber gesprochen? Im Interview erklärt Christian Schwendtner die Grundlagen beider Ansätze sowie die Unterschiede und Gemeinsamkeiten im Detail.

Christian Schwendtner


GraphQL & Angular – forget (the) REST? Christian Schwendtner: GraphQL ist vorrangig eine flexible Abfragesprache. Das sieht man auch auf der offiziellen Seite graphql.org, wo getitelt wird „A query language for your API“. Das trifft den Kern von GraphQL, denn die clientseitigen Datenbedürfnisse stehen im Vordergrund, die Möglichkeit, auf einfache und flexible Weise die benötigten Daten für Clients abfragen zu können. Ein spannender Punkt ist sicher die Flexibilität, die der Client gewinnt. Er kann einfach und genau definieren, welche Daten (inklusive Relationen) er vom Server benötigt. GraphQL ermöglicht eine sehr client- bzw. Use-Case-orientierte Sicht. Der Client kann mit einem Request genau die Daten laden, die er für einen Use Case bzw. eine Bildschirmmaske benötigt (kein Under- oder Overfetching).EM: Wie unterscheidet sich GraphQL von RESTful Web Services?Schwendtner: Diese Frage bekomme ich sehr oft gestellt, wenn Personen das erste Mal mit GraphQL in Berührung kommen. Bevor man diese Frage beantworten kann, ist es meiner Meinung nach wichtig, den Begriff RESTful Web Services etwas genauer unter die Lupe zu nehmen. Der Begriff ist an sich gut definiert, wird in der Praxis aber oft sehr inflationär verwendet. Wir sagen sehr gern zu jedem Service, der Ressourcen, HTTP-Verben und HTTP-Statuscodes verwendet und Daten in JSON zur Verfügung stellt, REST. Genau genommen stimmt das aber nicht. Von REST oder einem RESTful Web Service dürfte man eigentlich erst dann sprechen, wenn alle Kriterien, die Roy Fielding (der Erfinder von REST) definiert hat, erfüllt sind. Ein wichtiges Kriterium dabei ist HATEOAS, also Hypermedia as the Engine of Application State. Gerade HATEOAS wird aber bei vielen Services, die angeblich RESTful sind, nicht oder nicht ausreichend umgesetzt.Eine gute Möglichkeit, um eine Idee davon zu bekommen, „wie RESTful“ ein Service ist, bietet das Richardson-Maturity-Modell. In ihm sind verschiedene Level definiert, je nachdem, welche Aspekte von REST umgesetzt sind. Ein Service, der nur manche Kriterien von REST erfüllt (z. B. „nur“ Ressourcen, HTTP-Verben, Statuscodes, aber nicht HATEOAS) wird gerne REST-ish, REST-like oder REST-wannabe genannt. Das klingt jetzt vielleicht etwas nach Haarspalterei, aber ich denke es ist wichtig, dass man sich darüber im Klaren ist, was genau man mit GraphQL vergleicht – speziell, wenn es um den Vergleich mit RESTful Web Services geht.Meiner Erfahrung nach kann man sagen, dass GraphQL eine gute Alte...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang