Jetzt, wo Funktion und Zweck von GraphQL geklärt sind, bietet es sich an, eine sich womöglich stellende Frage zu klären: Grundsätzlich ließen sich APIs auch mit REST realisieren, warum hat man sich bei OXID also für einen anderen Weg und für GraphQL entschieden?
Im Netz kursieren bereits viele Vergleiche á la GraphQL vs. REST, wobei der Direktvergleich zwischen beiden an und für sich etwas hinkt. Wie an anderer Stelle bereits erwähnt, handelt es sich bei GraphQL um eine Abfragesprache, während REST (Representational State Transfer) im Kern „nur“ ein Architekturprinzip für netzwerkbasierte Software ist.
REST APIs für OXID gibt es einige. Dabei handelt es sich entweder um Open-Source-Lösungen oder individuelle Schnittstellen im Zuge von Projekten. Die OXID eSales AG selbst hat bis heute keine offizielle REST API für die Anbindung unabhängiger Systeme veröffentlicht. Der Grund dafür liegt in der Natur von „standardisierten“ REST APIs, die im Alltag häufig mit den folgenden Problemen behaftet sind:
Overfetching: REST-APIs neigen zum Overfetching, was bedeutet, dass Sie als Ergebnis einer Anfrage mehr Informationen erhalten, als Sie eigentlich benötigen. Ein gutes Beispiel hierfür ist die Abfrage von Kundendaten: Stellen Sie sich vor, Sie erhalten auf Ihre Suchanfrage nach bestimmten Kund:innen deren Namen, Anschrift, den Kontakt eines Verantwortlichen und eine Kundennummer, obwohl Sie nur letztere in Erfahrung bringen wollten.
Underfetching: Das Pedant zum Overfetching ist das Underfetching, vor dem eine REST-API ebenfalls nicht gefeit ist. Vor allem in speziellen Anwendungsfällen kann es vorkommen, dass eine Anfrage zu wenig Informationen liefert. Wollten Sie beispielsweise zu den oben genannten Kundendaten auch noch die Bestellhistorie in Erfahrung bringen, wird sehr wahrscheinlich auch noch eine zweite Abfrage fällig, denn Sie müssten Ihre Bestellinformationen zusätzlich abrufen. Mehr Abfragen gehen zulasten der Performance, das gilt vor allem dann, wenn beide Informationen aufwendig zu einem Objekt zusammengeführt werden sollen.
Versionierung: Änderungen an bestehenden Funktionen und neue Features führen dazu, dass eine REST API im Geschäftsalltag häufig versioniert werden muss, das macht diese anfälliger für Kompatibilitätsprobleme.
GraphQL wurde genau zu dem Zweck entwickelt, diesen Problemen zu begegnen und ist eine gute Wahl, wenn es darum geht, einer Vielzahl von Anwendern eine API als Basismodul zur Verfügung zu stellen.
