Application Programming Interfaces in der App-Entwicklung GraphQL vs. REST APIs

APIs (Application Programming Interfaces) gibt es schon seit Jahrzehnten. Aber erst seit sie zu einem zentralen Bestandteil der Softwareentwicklung geworden sind, hat ihre intensive Nutzung so richtig Fahrt aufgenommen. Denn APIs haben die Entwicklung von Anwendungen und Microservices vereinfacht, da gängige Funktionen wiederverwendet werden können.

Nicht nur mehr APIs werden mittlerweile verwendet, auch die API-Typen selbst sind vielfältiger geworden: REST, SOAP, GraphQL, Kafka-basierte APIs, auf Publish/Subscribe-Mustern basierende APIs, Remote Procedure Call-Protokolle oder sogar Webhooks – heutzutage stehen viele verschiedene API-Typen für Projekte zur Verfügung. Und alle kommen zum Einsatz. So hat der State of APIs Report 2022 festgestellt, dass alle API-Typen stärker genutzt werden, als noch im Vorjahr.

Manche Entwickler*innen entscheiden sich für einen bestimmten API-Typ wegen der gebotenen Leistung, Skalierbarkeit oder Zuverlässigkeit. Andere wiederum wählen eine API, weil sie den Entwicklungsprozess vereinfacht oder es ermöglicht, Code leichter zu ändern. Die Unterschiede zwischen den verschiedenen API-Typen sind groß. Bei einigen handelt es sich um Architekturstile wie REST, bei anderen um Frameworks oder Abfragesprachen (wie GraphQL).

Wenn es um die APP-Entwicklung geht, stehen REST APIs und GraphQL oft in der Endauswahl. Schauen wir uns genauer an, was diese beiden API-Typen ausmacht und wie sie verwendet werden.

REST APIs

REST (REpresentative State Transfer) ist ein Architekturstil, der erstmals im Jahr 2000 von Roy Fielding beschrieben wurde. Seitdem werden REST APIs zum Aufrufen von Ressourcen verwendet und ermöglichen die Kommunikation von Software auf der Grundlage standardisierter Prinzipien, Eigenschaften und Beschränkungen. Tatsächlich wurde das Wachstum der API-Economy durch REST APIs vorangetrieben.

REST-APIs arbeiten mit einem einfachen Anfrage/Antwort-System. Die Anfrage beinhaltet HTTP-Methode (GET, POST, PUT, PATCH, DELETE), Endpunkt, URL-Parameter und Body. Die Antwort gibt die angefragten Daten in Formaten wie JSON, XML, Plain Text, Bilder, HTML und andere zurück.

REST APIs können mit vielen verschiedenen Endpunkten entworfen werden, die unterschiedliche Ressourcen-Typen als Antwort zurückgeben. Für den Zugriff auf mehrere Endpunkte sind bei einer REST API jedoch mehrere Anfragen erforderlich, was die Leistung der Anwendung beeinträchtigen kann.

Ein großer Vorteil von REST APIs ist, dass sie leicht zu erlernen sind und dass sie so weitverbreitet sind, dass die meisten Developer mit ihnen vertraut sind. Laut des State of APIs Reports 2022 wurden REST APIs von 69 Prozent der befragten Entwicklerinnen und Entwickler in der Produktion eingesetzt. REST APIs sind damit der bei Weitem am häufigsten verwendete API-Typ.

Infolgedessen verfügt fast jede Plattform und jedes Framework über eine integrierte Bibliothek, die eine Schnittstelle zu einer REST API bietet. In anderen Worten: REST APIs sind sehr interoperabel. Außerdem sind REST APIs wiederverwendbar und ermöglichen die einfache Erstellung von Microservices, die unabhängig voneinander funktionieren, da sie von den Clients entkoppelt sind und von mehreren Anwendungen genutzt werden können.

Der Nachteil einer REST-API-Architektur ist, dass die Art der Ressource stark an den Endpunkt gebunden ist, über den sie abgerufen wird. Wie bereits erwähnt, gibt es für jeden Ressourcentyp einen eigenen Endpunkt zum Abrufen. Infolgedessen haben die Entwickler*innen weniger Kontrolle darüber, welche Daten sie genau abrufen, da die Objektstruktur im Server fest einkodiert wird. Dies führt dazu, dass in manchen Situationen zu viele Daten abgerufen werden, was die Ladezeit negativ beeinflusst.

Nehmen wir ein einfaches Beispiel, etwa den Abruf von Daten über ein Unternehmen (einschließlich Name und Standort) und seine Gründer. Bei einer REST API wären hier zwei separate Anfragen erforderlich. Die erste Anfrage, GET /company, gibt alle über das Unternehmen gespeicherten Informationen wieder, unter anderem eine founder_id, die dann in einer zweiten GET /founder alle mit den Gründern verbundenen Daten abruft:

Wären die erforderlichen Informationen komplexer, würde es noch weitere Anfragen erfordern, um die Daten abzurufen. Daher eignen sich REST APIs besonders für Anwendungen mit einer einfachen Datenstruktur oder wenn nur wenige aufeinanderfolgende Anfragen benötigt werden, um die benötigten Daten abzurufen. Für Projekte mit einer komplexen Datenstruktur und vielen verschiedenen Anfragen ist GraphQL möglicherweise besser geeignet.

GraphQL

GraphQL ist eine Open-Source-Abfragesprache, die Facebook 2012 zur Implementierung des News Feed-Bereichs für iOS entwickelt hat. Der News Feed musste derart viele Daten abfragen (Beiträge, Profilbilder, Kommentare, Likes usw.), sodass viele Fehler auftraten, weil es keine Konvention für den Datenaustausch zwischen den verschiedenen Front- und Backends gab.

Im Gegensatz zu REST APIs gibt es bei GraphQL APIs nur einen einzigen Endpunkt, um alle erforderlichen Daten abzurufen. Die größten Stärken von GraphQL sind die Möglichkeit, genau zu steuern, welche Informationen vom Server empfangen werden und diese Daten in einer vorhersehbaren Struktur zu erhalten, sowie die Möglichkeit, Daten aus mehreren Quellen in einer einzigen Anfrage anzufordern.

Um die Unternehmensinformationen und die Daten über die Gründer aus dem vorherigen Beispiel mit GraphQL abzurufen, muss nur eine einzige Anfrage an den Server gestellt werden. Das liegt daran, dass GraphQL auf einem stark typisierten Schema beruht. Das vordefinierte Schema ermöglicht es dem Client, die genaue Form der zurückgegebenen Daten zu bestimmen. Das Schema definiert eine Struktur dafür, wie die Daten – die aus Backend-Datenspeichern stammen – formatiert und verschachtelt werden. In unserem Beispiel müssten wir das Schema der API definieren:

Dann können wir als Teil der Anfrage an GraphQL genau festlegen, welche Daten unsere Anwendungen aus diesem Schema benötigen. In unserem Beispiel benötigen wir den Firmennamen, den Firmenstandort und die Namen der Gründer. Die Struktur der Abfrage ermöglicht es uns, die Daten von mehreren Ressourcen mit nur einer Abfrage anzufordern:

Dadurch, dass GraphQL die genaue Definition der Struktur von Anfrage und Antwort ermöglicht, können die zum Abrufen von Daten erforderlichen Ressourcen und Bandbreite reduzieren werden, da nur die gewünschten Daten in die Antwort aufgenommen werden. GraphQL APIs sind eine gute Wahl bei komplexen Datenstrukturen und wenn verschiedene Daten abgefragt werden müssen.

Der Nachteil von GraphQL ist, dass dieser API-Typ relativ neu ist und wenige Developer mit der Struktur vertraut sind. Laut des State of API 2022 Reports verwenden nur 19 Prozent der befragten Entwickler und Entwicklerinnen GraphQL in der Produktion. Außerdem kommt seine große Flexibilität mit einem Preis. Je nach Anwendungsfall kann die Einrichtung des Schemas komplexer sein als bei einfachen REST-Anfragen. Es gibt zwar viele Starter-Kits und Beispiele für die Strukturierung von GraphQL-Projekten, aber jede reale Implementierung erfordert eine individuelle Konfiguration und eine unternehmensspezifische Infrastruktur, was den Set-up erschwert.

Letztlich sind sowohl REST als auch GraphQL eine gute Wahl. Für die Entscheidungsfindung sollte man sich allerdings Zeit nehmen, um die verfügbaren Ressourcen genauer zu analysieren und die Anforderung der Anwendung genau zu definieren. Denn auch wenn GraphQL immer beliebter wird, ist dieser API-Typ nicht unbedingt die richtige Lösung für jede Situation.

* Alex Walling ist Field-CTO bei Rapid.

(ID:49193839)