GraphQL vs. REST: Was eignet sich besser für die Entwicklung von Schnittstellen?
CMS und Shopsysteme sind keine Allround-Lösungen für die Webpräsenz, die alles kann. Angesichts immer mehr neuer und komplexer werdender Anforderungen wäre dieser Anspruch utopisch. Vielmehr sind die Systeme das Fundament, auf dem eine individuelle Webseite entstehen kann. Dies wird seit geraumer Zeit über Schnittstellen realisiert, über die sich neue Systeme und Funktionen integrieren lassen. Dabei war der Representational State Transfer, kurz REST, lange der dominierende Standard für Web-APIs. Mit GraphQL bekommt dieser nun Konkurrenz. In diesem Blogbeitrag schauen wir deshalb auf die Gemeinsamkeiten und Unterschiede beider Prinzipien und klären die Frage, welche von Ihnen für Ihr Projekt besser geeignet ist.
Ein kurzer Steckbrief
Die REST- oder auch RESTful-Architektur ist das Ergebnis einer Doktorarbeit von Roy Fielding, einem US-amerikanischen Informatiker, aus dem Jahr 2000. Sein REST-Protokoll beruht auf sechs Prinzipien, wobei vor allem das Prinzip der Zustandslosigkeit essenziell für die Struktur von mit REST programmierten Schnittstellen (REST-APIs) ist. Es besagt, dass jede Nachricht alle zum Verständnis notwendigen Informationen enthalten muss. Obwohl REST grundsätzlich mit jedem Protokoll oder Dateiformat kompatibel ist, wird für gewöhnlich das HTTP-Protokoll verwendet. Die Datenübertragung geschieht in der Regel via JSON (JavaScript Object Notation).
Für mehr als ein Jahrzehnt sollte die REST-Architektur als Standard für die Erstellung von Schnittstellen konkurrenzlos bleiben, bis Facebook im Jahre 2012 die Abfragesprache GraphQL entwickelte. Inzwischen ist diese open source und wurde der Linux Foundation übergeben. Für die Datenverarbeitung gehen REST und GraphQL unterschiedliche Wege. Während REST sämtliche Informationen einer Abfrage übermittelt, will GraphQL nur notwendige Daten übertragen. Dazu werden die Anfragen mit von Entwicklern erstellen Schemen abgeglichen, sogenannte Resolver weisen den abgefragten Objekttypen dann passende Werte zu.
Vorteile von GraphQL
- Gezielte Datenabfrage: Es werden nur die Daten ausgegeben, die auch tatsächlich angefragt worden sind, was ein Aufkommen irrelevanter Informationen verhindert (kein Overfetching).
- Wenig Raum für Fehlkommunikation: Dadurch, dass die Objekttypen bei GraphQL-Abfragen definiert sind, kann ausgeschlossen werden, dass die Kommunikation von Client und Server aneinander vorbeiläuft.
- Weiterentwicklung ohne Versionierung: Eine API kann um neue Funktionen bereichert werden, ohne dass bestehende Abfragen dadurch beeinträchtigt sind.
- Keine spezifische Anwendungsstruktur: GraphQL kann auch auf einer vorhandenen REST-API installiert und über die klassischen API-Management-Tools, z.B. dem API-Management von Microsoft Azure, verwendet werden.
Vorteile von REST
- Etablierter Ansatz: Da REST schon seit mehr als 20 Jahren in der Programmierung von Schnittstellen eingesetzt wird, hat sich der Ansatz fest in der Praxis etabliert.
- Eindeutige Identifizierung: Ein weiteres von Roy Fieldings definierten Prinzipien besagt, dass jeder Ressource eine eindeutige URL zugewiesen sein muss, was die Identifizierung der REST-API sehr vereinfacht.
- Vereinheitlichte Methoden: REST greift auf ein HTTP-Protokoll zu und bedient sich dessen Befehlen, wie beispielsweise GET (Abrufen einer Ressource) und POST (Erstellen einer Ressource). Dadurch dass dieses Prinzip immer Bestand hat, sind die Befehle überall auf der Welt gleich.
GraphQL oder REST:
Welchen Ansatz sollten Sie bei der API-Programmierung wählen? Die unbefriedigende Antwort zuerst: Das kommt ganz darauf an. Der vergleichsweise junge GraphQL-Ansatz sollte nicht als Ersatz für die Programmierung einer REST-API verstanden werden, sondern als Alternative, denn beide haben ihre Daseinsberechtigung.
Aus den Vorteilen und Merkmalen von GraphQL und REST ergeben sich deren Anwendungsbereiche. Soll Ihre API beispielsweise eine gezielte Datentyp-Abfrage ermöglichen und zu einem beliebigen Zeitpunkt erweitert werden, dann ist GraphQL sehr wahrscheinlich die bessere Wahl, da die Abfragesprache besonders performante Schnittstellen ermöglicht. Performance ist auch im E-Commerce-Umfeld ein Thema, das immer mehr an Bedeutung gewinnt. Hier kann GraphQL seine Vorteile voll ausspielen, weshalb man sich auch auf Seiten des populären Shopsystems OXID eShop dazu entschieden hat, eine offizielle OXID-API auf Basis der Sprache für die Schnittstellenentwicklung zu veröffentlichen. Eine offizielle REST API gibt es hingegen bis heute nicht.
Für die Verwendung von REST für die Schnittstellenentwicklung spricht, dass der Ansatz seit mehr als zwei Jahrzehnten überall auf der Welt zum Einsatz kommt. Wenn die sprach- und ortsunabhängige Entwicklung bei Ihrem Projekt im Vordergrund steht, dann sollten Sie auf REST setzen.
ESYON: Ihr Experte für Schnittstellenentwicklung
ESYON ist zertifizierter Partner für Mircosoft Dynamics, OXID eShop und Perfion. Mit Hilfe unseren eigens entwickelten Schnittstellen-Lösungen bringen wir die drei Welten Onlineshop, ERP und PIM zusammen. Gerne unterstützen wir auch Sie bei Ihrem Projekt, sei das Projektmanagement, die Integration neuer Systeme oder die individuelle Entwicklung. Sprechen Sie uns an!
array(8) { ["@type"]=> string(11) "NewsArticle" ["identifier"]=> string(16) "#/schema/news/13" ["headline"]=> string(81) "GraphQL vs. REST: Was eignet sich besser für die Entwicklung von Schnittstellen?" ["datePublished"]=> string(25) "2023-02-15T16:55:00+01:00" ["url"]=> string(26) "/aktuelles/graphql-vs-rest" ["description"]=> string(729) "CMS und Shopsysteme sind keine Allround-Lösungen für die Webpräsenz, die alles kann. Angesichts immer mehr neuer und komplexer werdender Anforderungen wäre dieser Anspruch utopisch. Vielmehr sind die Systeme das Fundament, auf dem eine individuelle Webseite entstehen kann. Dies wird seit geraumer Zeit über Schnittstellen realisiert, über die sich neue Systeme und Funktionen integrieren lassen. Dabei war der Representational State Transfer, kurz REST, lange der dominierende Standard für Web-APIs. Mit GraphQL bekommt dieser nun Konkurrenz. In diesem Blogbeitrag schauen wir deshalb auf die Gemeinsamkeiten und Unterschiede beider Prinzipien und klären die Frage, welche von Ihnen für Ihr Projekt besser geeignet ist." ["author"]=> array(2) { ["@type"]=> string(6) "Person" ["name"]=> string(13) "Steffi Greuel" } ["image"]=> array(6) { ["@type"]=> string(11) "ImageObject" ["caption"]=> string(0) "" ["contentUrl"]=> string(51) "/files/content/blog/stoerer/frau%20an%20klaptop.jpg" ["identifier"]=> string(51) "#/schema/image/a8e6bba1-9d89-11ee-b693-408d5c841e28" ["license"]=> string(0) "" ["name"]=> string(0) "" } }