In diesem ersten von insgesamt drei Beiträgen schaffen wir die theoretische Basis für das Verständnis für REST und GraphQL sowie deren wesentliche Unterscheidungsmerkmale.
Die beiden folgenden Artikel werden jeweils ein Anwendungsbeispiel für die beiden Technologien mithilfe von Amazon Web Services beinhalten.
Lesedauer 6 Minuten
REST (Representational State Transfer) ist ein heutzutage weit verbreitetes und bekanntes Softwarearchitektur Paradigma das in der Praxis vor allem für Webservices Verwendung findet. Es steht für einige Standards die im Web genutzt werden um es unterschiedlichen Systemen einfacher zu machen miteinander zu kommunizieren.
GraphQL ist eine Abfragesprache (Query Language) mit der Daten über das Web von einem API (Application Programming Interface) abgefragt oder bearbeitet werden können. Mithilfe dieser 2012 ursprünglich von Facebook entworfenen und entwickelten Technologie sollen flexiblere und effizientere Datenzugriffe als mit dem traditionellen REST-Ansatz ermöglicht werden.
Obwohl REST per Definition nicht an ein Protokoll gebunden ist, wird es in der Praxis fast ausschließlich in Verbindung mit HTTP verwendet um Informationen als Web-API zur Verfügung zu stellen.
Damit ein Service RESTful ist, muss es die folgenden Rahmenbedingungen berücksichtigen.
Die Zuständigkeiten werden getrennt. Der Server stellt Dienste bereit die vom Client genutzt werden können. Ein Server bedient dabei üblicherweise mehrere oder sogar eine Vielzahl an Clients.
Bei diesem Prinzip steht vor allem die unabhängige Entwicklung der beiden Komponenten im Fokus. Anpassungen an einem Client wie zum Beispiel einer Webanwendung müssen nicht mit Änderungen am Server einhergehen oder umgekehrt. Sie können individuell voneinander betrachtet werden und kommunizieren über eine definierte Schnittstelle.
Eine Anfrage enthält alle notwendigen Informationen die für die Verarbeitung am Server benötigt werden. Auf dem Server müssen also keine Zustandsinformationen gespeichert sein um die Aufgabe abzuarbeiten. Im üblichen Sprachgebrauch ist dann von stateless die Rede.
Das ermöglicht vor allem eine hohe Skalierbarkeit auf Serverseite da jeder Request für sich an einen anderen Server gesendet werden kann.
Die schnellste Abfrage ist diejenige die nicht gestellt werden muss. Nach diesem Prinzip sollen so viele Informationen wie möglich auf dem Client zwischengespeichert werden um weitere Anfragen an den Server und damit zusätzliche Wartezeiten zu vermeiden.
Das wohl wichtigste Prinzip von RESTful Services ist die einheitliche Schnittstelle. Anhand einer URL wird eine Ressource definiert auf die mit einer Methode (z.B. GET, POST, PUT) zugegriffen wird. Als Ergebnis einer Anfrage erhält man Informationen zu der angeforderten Ressource, was im gängigsten Fall in Form einer JSON-Antwort stattfindet. Das Format wird aber nicht zwingend vorgegeben.
Das System ist in mehrere Schichten aufgeteilt. Für den Nutzer ist die wichtigste Schicht die Schnittstelle mithilfe derer er mit dem Service kommuniziert. Die weiteren Schichten wie die Business Logik oder der Datenzugriff sind für den Anfragenden vollkommen transparent. Das ermöglicht es jederzeit flexibel einzelne Komponenten und Technologien zu tauschen, ohne dass sich dies auf Anwendungen die auf die Schnittstelle zugreifen auswirkt. Man spricht hier von einem lose gekoppelten System.
Hierdurch wird die Möglichkeit gegeben ausführbaren Code vom Server an den Client zu übertragen und dort auszuführen. Dadurch können Funktionen die eine bestimmte Logik ausführen ohne weitere zusätzliche Roundtrips zum Server direkt auf dem Client ausgeführt werden um weitere Anfragen zu vermeiden. Diese Rahmenbedingung ist als einzige der genannten optional. Ein Beispiel für Code on Demand wäre Javascript-Code der vom Server abgefragt und anschließend am Client ausgeführt wird.
Mithilfe dieser Abfragesprache wollten Entwickler vor allem die Geschwindigkeit, Effizienz und Flexibilität mit der Informationen im Web zugänglich gemacht werden signifikant erhöhen.
Das wird erreicht indem der Client bereits bei der Anfrage mitgibt welche Informationen er vom Server erhalten möchte. Neben einfachen Eigenschaften können durch die Abfrage auch gleich direkt in Beziehung stehende Objekte im Ergebnis mitberücksichtigt werden. Darüber hinaus ist es möglich in einer Anfrage mehrere Abfragen abzusetzen. Dies reduziert zum einen die Datenmenge die über die Leitung transportiert werden muss und gleichzeitig wird auch die Anzahl der Roundtrips vom Client zum Server verringert.
GraphQL Libraries gibt es für viele verschiedene Programmiersprachen (z.B. Javascript, Python, C#, Java).
Die wichtigsten Begrifflichkeiten im Umgang mit GraphQL sind Schema, Resolver, Query, Mutation und Subscription.
GraphQL definiert sich durch Eigenschaften die in einem Schema festgehalten sind. Diese Eigenschaften werden mithilfe einer Funktion, dem sogenannten Resolver, aufgelöst und liefern einen Wert zurück. Dieser Wert kann entweder ein Skalarwert wie eine Zahl, eine Zeichenkette oder ein Objekt das wiederum aus Eigenschaften eines Typs bestehen sein.
Als Query wird die entsprechende Abfrage bezeichnet die angibt welche Informationen im Ergebnis enthalten sein sollen. Das Format des Ergebnisses entspricht dabei dem Format der Abfrage.
Zusätzlich zu den Eigenschaften können in einigen Fällen auch ergänzend Parameter hinzugefügt werden die beispielsweise angeben wie viele untergeordnete Objekt (in unserem Beispiel comments) zurückgegeben bzw. wie diese sortiert werden sollen.
Mithilfe von Mutationen werden Änderungsoperationen durchgeführt. Das Format und die Eigenschaften des Ergebnisses werden dabei wieder vom Client bestimmt. Die zu speichernden Informationen werden als Parameter übergeben.
Eine Subscription bietet die Möglichkeit mithilfe von Websockets aktiv vom Server über Änderungen an Daten informiert zu werden. Dadurch wird vor allem Polling, also dem regelmäßigen Abfragen vom Client ob sich Änderungen ergeben haben, vorgebeugt um die Ressourcen wie Bandbreite und Rechenkapazität zusätzlich zu schonen.
| REST | GraphQL | |
|---|---|---|
| Erscheinungsjahr | 2000 | 2015 |
| Kategorie | Softwarearchitektur Paradigma | Abfragesprache |
| Integration | aufgrund des zumeist eingesetzten HTTP Standards werden keine zusätzlichen Komponenten benötigt | Verwendung von Libraries erforderlich |
| Performance | häufig sind mehrere Roundtrips zum Server notwendig um alle Daten abzufragen, außerdem werden immer alle Daten übertragen, auch wenn sie nicht benötigt werden, Caching einfach möglich | nur notwendige Daten werden in wenigen Roundtrips abgefragt, Caching ebenfalls gut möglich, Caching je nach eingesetzter Library möglich |
| Änderungen identifizieren | regelmäßiges Polling | Subscription |
| Unterstützte Datenformate | mehrere Formate möglich (JSON, CSV, XML. HTML, etc.) | JSON |
| Schnittstellenversionierung | unterstützt | üblicherweise keine Versionierung erforderlich |
| Zugriff | eine URL für jede Ressource | immer die gleiche URL, zusätzlich wird die Abfrage mitgegeben |
REST ist ein Paradigma in der Softwareentwicklung, GraphQL eine Abfragesprache. Dennoch dienen beide Ansätze dazu Informationen von einer Schnittstelle abzufragen bzw. Änderungen an den Daten vorzunehmen. GraphQL ist ein modernerer Ansatz der sich immer größer werdender Beliebtheit erfreut. Es wird am besten dort eingesetzt wo nicht immer alle Informationen benötigt werden oder auf Änderungen zeitnah reagiert werden muss. Hingegen ist REST seit Jahrzehnten akzeptiert und weit verbreitet, vor allem der einfache Zugriff mittels HTTP-Standard ist ein Pluspunkt und verringert Abhängigkeiten bei der Softwareentwicklung.
Als zertifizierter SQL Experte analysiert, konzipiert und berät Stefan KMUs, sowie Großkunden im D-A-CH-LI Raum bei technischen Fragen rund um ihre Daten. Vor allem die hocheffiziente Verarbeitung und betriebliche Absicherung der Daten sind seine Spezialität und ermöglicht häufig eine enorme Leistungssteigerung in den Unternehmen. Zusätzlich entwickelt er auf Basis moderner Datenbank- und KI-Technologien nachhaltige Cloud-Lösungen.
Full-Stack Developer – React JavaScript