Vergleich von Web Services Implementierungen: REST vs. JSON:API vs. GraphQL

Die Menschen von heute lassen sich ungern einschränken. Wenn ich über Entwicklungsteams spreche, würden diese das mit Nachdruck bestätigen. Da Entwicklung und Innovation Hand in Hand gehen und Einschränkung der größte Feind der Innovation ist, kann man ihnen diese Ansicht nicht verdenken. 

Speziell im Bereich der Webentwicklung gibt es viele Bereiche zu erkunden und viele Technologien, die dabei helfen. Warum sich also einschränken, wenn es nicht nötig ist? Drupal hat einen beeindruckenden Trend vorangetrieben, der das Innovationsbedürfnis der Entwickler:innen befriedigt hat: den Headless-Ansatz. 

Anders als früher, als Ihr gesamtes Projekt in einem einzigen CMS untergebracht werden musste, gibt Ihnen Drupal jetzt die Möglichkeit, neue Technologien nach Herzenslust zu erkunden. Dies ist möglich, weil die Präsentationsschicht und der Backend-Inhalt zu zwei getrennten Einheiten werden. Drupal fungiert als Content-Repository, und eine Frontend-Technologie Ihrer Wahl kümmert sich um den Frontend-Teil der Website-Architektur.

Um eine Verbindung zwischen den getrennten Entwicklungsaspekten des Projekts herzustellen, kommt die API ins Spiel. Eine API-Schicht ist eine Notwendigkeit, wenn man Headless arbeitet, da sie alle Informationen vom Frontend zum Backend und umgekehrt überträgt. 

Und die drei in Drupal verfügbaren APIs, REST, JSON und GraphQL, sind der Grund, warum ich diesen Blog schreibe. Obwohl der Zweck aller drei derselbe ist, unterscheiden sie sich doch erheblich voneinander. Heute werden wir ihre Bedeutung, ihre Vor- und Nachteile und alle sichtbaren Unterschiede hervorheben. Fangen wir also an. 

Die APIs entschlüsseln 

REST, JSON und GraphQL führen zu einem ähnlichen Ergebnis, wenn sie für die Entkopplung von Drupal verwendet werden. Ja, sie sind auch unterschiedlich. Und wir werden uns bald mit den Unterschieden zwischen REST, JSON und GraphQL befassen. Zuvor ist es wichtig, ihre Geschichte, ihren Ursprung und ihren ursprünglichen Zweck zu verstehen, denn die Unterschiede beginnen eigentlich dort. 

REST 

REST wurde im Jahr 2000 von Roy Fielding entwickelt. Der Zweck der Entwicklung war es, einen Softwarearchitektur-Entwurf für APIs bereitzustellen. Einfach ausgedrückt, bot es einen einfachen Weg für einen Computer, mit einem anderen zu interagieren, indem er ein HTTP-Protokoll verwendete. Die Kommunikation zwischen den beiden Computern wird nicht auf dem Server gespeichert, d. h. sie ist zustandslos; stattdessen werden die Client-Sitzungen auf einem Client-seitigen Server gespeichert. 

Es gibt sechs Einschränkungen, die notwendig sind, um REST im vollen Umfang zu implementieren. 

• Es benötigt einen getrennten Client und Server; 
• Es muss in der Lage sein, unabhängige Aufrufe zu tätigen;
• Es muss in der Lage sein, zwischenspeicherbare Daten zu speichern;
• Es muss eine einheitliche Schnittstelle haben;
• Es ist ein mehrschichtiges System; 
• Schließlich benötigt es einen Code-on-Demand. 

REST bietet eine große Funktionalität ohne viel Aufwand. Wenn Sie beispielsweise an der RESTful-API einer anderen Person arbeiten, benötigen Sie keine spezielle Bibliothek oder spezielle Initialisierung. Ja, Ihre Entwickler:innen müssen ihr eigenes Datenmodell mit REST entwerfen, aber die HTTP-Konventionen machen die Programmierung zum Kinderspiel. 

Um zu erfahren, wie REST eine Schlüsselrolle bei der Entkopplung von Drupal spielt, lesen Sie unseren Blog REST-APIs in Drupal.

JSON: API  

JSON steht für JavaScript Object Notation. Es wurde im Mai 2013 entwickelt und als Kodierungsschema konzipiert, wodurch der Bedarf an Ad-hoc-Code für jede Anwendung zur Kommunikation mit Servern entfällt, die eine definierte Methode für dasselbe verwenden. JSON: API ist, wie der Name schon sagt, eine Spezifikation für die Erstellung von APIs mit JSON. 

Mit JSON: API wird die Kommunikation zwischen Server und Client äußerst komfortabel. Es formatiert nicht nur die Art und Weise, wie eine Anfrage geschrieben werden soll, sondern auch die Antworten kommen in formatierter Form. Das Hauptziel von JSON: API ist es, die Anzahl der Anfragen zu verringern und die Größe des Pakets zu reduzieren, und das alles unter Verwendung des HTTP-Protokolls. 

Allgemein gesagt; 

• JSON reduziert die Anzahl der Anfragen und die Menge der übertragenen Daten; 
• Es erfordert keine Konfiguration; 
• Es verwendet dasselbe JSON-Zugriffsschema für jedes Datenelement, wodurch das Caching sehr effektiv ist;
• Es bietet eine ganze Reihe von Funktionen und gibt Ihnen als Client die Möglichkeit, diese ein- oder auszuschalten. 

Um zu erfahren, wie JSON:API eine Schlüsselrolle bei der Entkopplung von Drupal spielt, lesen Sie unseren Blog JSON API in Drupal.

GraphQL 

Während JSON zusammen mit REST funktionieren kann, wurde GraphQL als Alternative dazu und zu einigen seiner Unannehmlichkeiten entwickelt. Es wurde 2012 von Facebook entwickelt und fungiert als plattformübergreifende Datenauskunfts- und Manipulationssprache. Seine Server sind in zahlreichen gängigen Sprachen verfügbar, darunter Java, JavaScript, Ruby, Python, C# und andere. 

Die Funktionen von GraphQL sind: 

• Es ermöglicht Benutzern, Daten aus mehreren Ressourcen in einer einzigen Anfrage anzufordern.
• Es kann verwendet werden, um Ad-hoc-Abfragen an einen Endpunkt zu richten und auf alle benötigten Daten zuzugreifen.
• Es gibt dem Client die Möglichkeit, den genauen Datentyp anzugeben, der vom Server benötigt wird. 
• All dies trägt zu seiner vorhersagbaren Datenstruktur bei, wodurch es sowohl lesbar als auch effizient ist. 

Erst 2015, nachdem GraphQL als Open Source veröffentlicht wurde, wurde es wirklich populär. Jetzt wird seine Entwicklung von der GraphQL Foundation gesteuert, die von der Linux Foundation gehostet wird. 

Um zu erfahren, wie GraphQL eine Schlüsselrolle bei der Entkopplung von Drupal spielt, lesen Sie unseren Blog GraphQL in Drupal.

Nachdem wir nun die Grundlagen aller drei APIs kennen, wollen wir uns vor dem Vergleich ihren Popularitätsstatus ansehen. 

REST vs. JSON vs. GraphQL 

Lassen Sie uns nun ins Detail gehen und verstehen, warum es in Ihrem besten Interesse sein könnte, sich für eine der beiden anderen zu entscheiden. Beginnen wir mit den Unterschieden zwischen REST, JSON:API und GraphQL.

Wie effizient ist der Datenabruf?

Einer der wichtigsten Aspekte für eine API ist die Art und Weise, wie sie Daten abruft. Es kann eine oder mehrere Anfragen erfordern. Daher wird dieser Aspekt auch als Anfrageeffizienz bezeichnet. Mehrere Datenantworten in einer einzigen Anfrage zu erhalten, sollte ideal sein. Sehen wir uns also an, wie REST, JSON: API und GraphQL hier abschneiden. 

REST 

Die REST-API ist von Natur aus darauf ausgelegt, eine Ressource pro Anfrage zu nutzen. Dies funktioniert perfekt, solange Sie nur ein einzelnes Datenelement wie einen Artikel abrufen müssen. Wenn Sie jedoch mehr benötigen, entspricht die Anzahl der Anfragen, die Sie separat eingeben müssten, der Menge der Daten, die Sie benötigen. 

Ein Artikel = eine Anfrage 
Zwei Artikel = zwei Anfragen
Zwei Artikel und die in einem anderen Feld gespeicherten Autoreninformationen = Zwei Anfragen für die Artikel + langes Warten auf den Abschluss dieser Anfragen + zwei zusätzliche Anfragen für die Autoreninformationen. 

Dies fasst die Anfrageeffizienz von REST auf den Punkt zusammen. Sie müssen in der Lage sein, eine Reihe von Anfragen zu bearbeiten, was letztendlich Ihre Benutzererfahrung beeinträchtigen und sie langsam erscheinen lassen kann. Keine Schönfärberei, es wird eine Menge Roundtrips geben. 

Und das Problem bei vielen Roundtrips ist eine Menge zusätzlicher Informationen, die Sie nicht einmal benötigen. Dies liegt daran, dass ein REST-API-Endpunkt möglicherweise nicht die erforderlichen Daten für eine Anwendung enthält. Infolgedessen erhält die besagte Anwendung nicht alles, was sie benötigt, in einem einzigen Durchgang, was mehrere Durchgänge zur einzigen Option macht. Man kann mit Sicherheit sagen, dass REST zu viele Daten abruft und die ausführlichen Antworten ein Problem darstellen können.

JSON: API 

JSON: API leidet nicht unter dem Problem der Mehrfachanfragen. Eine einzige Anfrage kann Ihnen alles geben, was Sie wollen, sei es ein Artikel, zwei oder zehn zusammen mit den Informationen des Autors, ich mache keine Witze. 

Dies ist möglich, weil JSON: API ein Konzept namens "Sparse Fields" implementiert. Dies listet die gewünschten Ressourcenfelder zur einfachen Abfrage zusammen auf. Sie können so viele Felder wie möglich haben. Wenn Sie der Meinung sind, dass die Felder zu lang sind und nicht zwischengespeichert werden können, können Sie einfach ein paar Sparse Fieldsets weglassen, um die Anfrage zwischenzuspeichern. 

Eine weitere Sache, die Sie beachten sollten, ist, dass die Server sinnvolle Standardwerte wählen können, sodass Ihre Entwickler:innen ein wenig sorgfältig sein müssen, um ein Überabrufen zu vermeiden. 

GraphQL 

GraphQL wurde ähnlich wie JSON: API entwickelt und ist kompetent genug, um das Problem des Überabrufens zu beseitigen und das Senden mehrerer Anfragen zu vermeiden. 

GraphQL verfügt über eigene Abfragen, Schemata und Resolver, die die Entwickler:innen bei der Erstellung von API-Aufrufen mit bestimmten Datenanforderungen unterstützen. Darüber hinaus kann es mehrere Roundtrips vermeiden, indem es klare Ergänzungen zu jedem Ressourcenfeld in jeder Abfrage vorschreibt und sicherstellt, dass die Entwickler:innen keine davon überspringen können. Dadurch gehört das Überabrufen von Informationen der Vergangenheit an. 

Das einzige Problem hierbei kann sein, dass die Abfragen zu groß werden und folglich nicht zwischengespeichert werden können. 

Wie wird der Code ausgeführt?

Die Verwendung einer API für Aufrufe beinhaltet die Ausführung eines Codes auf dem Server. Dieser Code hilft bei der Berechnung, dem Aufruf einer anderen API oder dem Laden von Daten aus einer Datenbank. Alle drei APIs verwenden einen Code, die Implementierung des Codes variiert jedoch ein wenig.

REST 

Routen-Handler werden für die Ausführung bei einem REST-Aufruf verwendet. Dies sind im Grunde Funktionen für bestimmte URLs. 

• Zuerst empfängt der Server den Aufruf und ruft den URL-Pfad und GET ab; 
• Dann werden die Funktionen notiert und der Server beginnt, diese zu finden, indem er GET und den Pfad abgleicht; 
• Danach wird das Ergebnis generiert, da der Server die Funktion ausgeführt hätte; 
• Im letzten Schritt ist das Ergebnis, sobald es von der API-Bibliothek serialisiert wurde, für den Client sichtbar. 

GraphQL

GraphQL arbeitet auf relativ ähnliche Weise. Der einzige Unterschied besteht darin, dass es Funktionen für ein Feld innerhalb eines Typs verwendet, wie z. B. einen Abfragetyp, anstatt Funktionen für bestimmte URLs zu verwenden. 

Routen-Handler werden in GraphQL durch Resolver ersetzt, es sind aber immer noch Funktionen.

• Nachdem der Aufruf getätigt wurde und der Server eine Anfrage erhalten hat, wird die GraphQL-Abfrage abgerufen. 
• Die Abfrage wird dann untersucht und der Resolver wird für jedes Feld aufgerufen. 
• Schließlich wird das Ergebnis von der GraphQL-Bibliothek zur Antwort hinzugefügt und ist für den Client sichtbar. 

Es sollte beachtet werden, dass GraphQL viel mehr Flexibilität bietet, da mehrere Felder in einer Anfrage angefordert werden können und dasselbe Feld mehrmals in einer Abfrage aufgerufen werden kann. Die Tatsache, dass sie Ihnen mitteilen, wo Sie Ihre Leistung optimieren müssen, macht Resolver auch zu hervorragenden Trackern. 

Dies ist in REST und JSON einfach nicht möglich. Sehen Sie den Unterschied in der Implementierung?

Welche Rolle spielen die API-Endpunkte?

Oft wird festgestellt, dass sobald die API entworfen und die Endpunkte versiegelt sind, die Anwendungen Frontend-Iterationen erfordern, die nicht vermieden werden können. Sie müssen wissen, dass die Endpunkte einer Anwendung helfen, die erforderlichen Daten zu erhalten, indem sie einfach schnell in der Ansicht darauf zugreifen, sodass Sie sie sogar als wesentlich bezeichnen könnten. 

Die Endpunkte können jedoch ein Problem für die Iterationen darstellen, insbesondere wenn diese schnell sein müssen. Da in einem solchen Fall Änderungen an den API-Endpunkten für jede Änderung im Frontend vorgenommen werden müssen, wird das Backend ohne Grund mühsam. Die dafür benötigten Daten können eher schwer oder eher leicht sein, was letztendlich die Produktivität beeinträchtigt. 

Welche API bietet also die Lösung?

Es ist weder REST noch JSON. Die Flexibilität von GraphQL macht es den Entwickler:innen leicht, Abfragen zu schreiben, in denen die spezifischen Datenanforderungen zusammen mit Iterationen für die Entwicklung des Frontends erwähnt werden, ohne dass das Backend die Hauptlast tragen muss.

Darüber hinaus helfen die Abfragen von GraphQL den Entwickler:innen beim Abrufen spezifischer Datenelemente und geben dem Benutzer Einblicke, welche Elemente bei den Clients beliebt sind und welche nicht. 

Warum nicht REST? 

Die Antwort ist einfach, REST hat alle Daten in einem einzigen API-Endpunkt. Als Benutzer können Sie keine Einblicke in die Verwendung spezifischer Daten gewinnen, da immer die Gesamtheit davon zurückgegeben wird. 

Wie gut ist die API-Erkundung?

Ihre API zu verstehen und alle ihre Ressourcen schnell und einfach zu kennen, wird Ihren Entwickler:innen immer zugute kommen. In diesem Aspekt schneiden alle drei ziemlich gegensätzlich ab. 

REST 

REST bietet ehrlich gesagt eine glanzlose Leistung bei der API-Erkundung. Die Interaktivität ist ziemlich unterdurchschnittlich, da die Navigationslinks selten verfügbar sind. 

In Bezug auf das Schema wäre es nur programmierbar und validierbar, wenn Sie den OpenAPI-Standard verwenden würden. Die automatische Generierung der Dokumentation hängt ebenfalls davon ab. 

JSON: API 

JSON schneidet besser ab als REST. Die Beobachtung der verfügbaren Felder und Links in den Antworten von JSON: API hilft bei der Erkundung und macht die Interaktivität recht gut. Sie können es mit einem Webbrowser, cURL oder Postman erkunden. 

Das Durchsuchen von einer Ressource zur nächsten, das Debuggen oder sogar der Versuch, auf einer HTTP-basierten API wie REST zu entwickeln, kann über einen Webbrowser zusammen mit JSON erfolgen. 

GraphQL 

GraphQL ist in der Tat der Spitzenreiter hier. Es hat eine beeindruckende Funktion, die als GraphiQL bekannt ist, aufgrund derer die API-Erkundung unübertroffen ist. Es ist eine In-Browser-IDE, die es den Entwickler:innen ermöglicht, wiederholt Abfragen zu erstellen. 

Noch beeindruckender ist die Tatsache, dass die Abfragen basierend auf den Vorschlägen, die sie liefert, automatisch vervollständigt werden und Sie Echtzeitergebnisse erhalten. 

Konzentrieren wir uns nun auf das Schema 

Schemata sind für das Entwicklungsteam, das Frontend und das Backend gleichermaßen wichtig. Dies liegt daran, dass Ihr Team die Datenstruktur kennt und parallel arbeiten kann, sobald ein Schema definiert wurde. Das Erstellen von Dummy-Testdaten sowie das Testen der Anwendung wäre für die Frontend-Entwickler:innen einfach. Alles in allem steigen die Produktivitäts- und Effizienzwerte. 

REST

REST hat zwar ein zugehöriges erwartetes Ressourcenschema, da es sich um eine Reihe von Standardformulierungen handelt. Trotzdem gibt es nichts, was in ihnen speziell angegeben ist. 

JSON: API 

In Bezug auf die Schema-Validierung und -Programmierung definiert es zwar ein generisches, aber ein zuverlässiges Schema auf Feldebene ist noch nicht zu sehen. Einfach ausgedrückt, JSON ist in Bezug auf das Schema einfach. 

GraphQL

Die Tatsache, dass GraphQL vollständig auf Schemata basiert, macht es in dieser Hinsicht zu einem Profi. Das hier verwendete Schema ist Schema Definition Language oder SDL. Dies bedeutet, dass GraphQL ein Typsystem verwendet, das die Typen in einer API festlegt, da alle Typen in SDL enthalten sind. Somit wird das Definieren der Art und Weise, wie ein Client auf Daten auf dem Server zugreifen soll, einfach. 

Um diesen Punkt abzuschließen, möchte ich sagen, dass es für die API von Nachteil sein kann, wenn das Schema und die Ressourcenbeziehungen immens komplex sind. 

Wie einfach ist es, es zu bedienen? 

Die Bedienung einer API umfasst im Wesentlichen alles, von der Installation und Konfiguration bis hin zur Skalierung und Sicherung. REST, JSON: API und GraphQL funktionieren alle gut genug, um sich einfach bedienen zu lassen. Sehen wir uns an, wie. 

REST 

REST ist recht einfach zu bedienen, ein Spaziergang im Park für einen professionellen Entwickler. Dies liegt daran, dass REST von den herkömmlichen HTTP-Formulierungen und -Techniken abhängig ist. Sie müssten die zugrunde liegenden Ressourcen nicht viel transformieren, da sie von fast allem unterstützt werden können. Es stehen den Entwickler:innen auch viele Tools zur Verfügung, diese sind jedoch von ihrer Anpassung abhängig, bevor sie implementiert werden können. 

In Bezug auf die Skalierung ist REST extrem skalierbar, die Handhabung von Websites mit hohem Datenverkehr ist überhaupt kein Problem. Um dies auszunutzen, können Sie einen Reverse-Proxy wie Varnish oder CDN verwenden. Ein weiterer Pluspunkt von REST ist, dass es begrenzte Fehlerpunkte hat, nämlich den Server und den Client. 

JSON: API 

JSON: API ist in Bezug auf die betriebliche Einfachheit mehr oder weniger dasselbe wie REST, so sehr, dass Sie ohne umfangreiche Kosten von REST zu JSON: API wechseln können. 

• Es basiert auch auf HTTP; 
• Es ist auch extrem skalierbar; 
• Es hat auch zahlreiche Entwicklertools, aber im Gegensatz zu REST benötigt JSON: API keine kundenspezifischen Implementierungen; 
• Schließlich hat JSON auch weniger Fehlerpunkte. 

GraphQL 

GraphQL ist hier der Außenseiter. Es ist nicht so einfach zu bedienen wie die anderen beiden. Es erfordert eine spezifische relationale Struktur und spezifische Mechanismen für die Verriegelung. Sie würden denken, wie ist das komplex? Lassen Sie mich Sie bitten, sich auf das Wort spezifisch zu konzentrieren, was bedeutet, dass Sie möglicherweise Ihre gesamte API in Bezug auf die Ressourcenlogik umstrukturieren müssen. Und Sie müssen wissen, dass eine solche Umstrukturierung Sie Zeit, Geld und eine Menge Mühe kosten würde. 

Auch in Bezug auf die Skalierbarkeit schneidet GraphQL nicht sehr gut ab. Selbst die einfachsten Anfragen verwenden in der Regel GET-Anfragen. Damit Sie GraphQL wirklich nutzen können, benötigen Ihre Server eigene Tools. Wenn ich über die Fehlerpunkte hier spreche, gibt es sogar viele, einschließlich Client, Server, Client-seitiges Caching sowie Client- und Build-Tools. 

Was ist mit Sicherheit?

Die Art der Sicherheit, die eine API bietet, ist ebenfalls eine wichtige Überlegung bei der Auswahl. Ein drastischer Unterschied wird in REST und GraphQL festgestellt. Sehen wir uns an, was das ist. 

REST 

REST ist die sicherste unter den dreien. Die intrinsischen Sicherheitsfunktionen in REST sind der Grund für die Leistung. 

• Es gibt verschiedene APU-Authentifizierungsmethoden, einschließlich der HTTP-Authentifizierung;
• Es gibt die JSON-Web-Token für sensible Daten in HTTP-Headern;
• Es gibt auch die Standard-OAuth 2.0-Mechanismen für sensible Daten in der JSON-Struktur. 

JSON:API

JSON:API ist in Bezug auf die Sicherheit auf einer ähnlichen Stufe wie REST. Der Grund dafür ist, dass es wie REST wenig Ressourcen freigibt. 

GraphQL 

Es ist nicht so, dass GraphQL nicht sicher ist, es ist es; die Sicherheit muss jedoch manuell erreicht werden. Es ist nicht standardmäßig sicher und in dieser Hinsicht nicht so ausgereift wie REST. 

Wenn der Benutzer Authentifizierungs- und Autorisierungsmaßnahmen zusätzlich zur Datenvalidierung anwenden muss, steigen die Chancen auf unvorhersehbare Autorisierungsprüfungen. Muss ich Ihnen jetzt sagen, dass ein solches Ereignis Ihre Sicherheit gefährden wird?

Wie wird das API-Design genau bestimmt?

Wenn eine API für jeden Anwendungsfall gut funktionieren soll, müssen Sie sie dazu bringen. Indem Sie solche Designentscheidungen treffen, die ein Ergebnis Ihres Verständnisses der Bedürfnisse der Benutzer sind. Sie können nicht einfach mit dem Strom schwimmen, die Bewertung, wie Ihre Benutzer mit Ihrer API interagieren werden, und das Verständnis dafür ist der Schlüssel für das Design Ihrer API. 

REST

Für REST muss diese Übung des Entschlüsselns der Benutzeranforderungen stattfinden, bevor die API implementiert werden kann. 

GraphQL 

Bei GraphQL kann diese Befürchtung etwas verzögert werden. Durch die Profilierung der Abfragen können Sie deren Komplexitätsgrad erkennen und die trägen Abfragen genau bestimmen, um ein Verständnis für den Konsum der API durch den Benutzer zu erhalten. 

Was ist mit ihrer Verwendung in Drupal? 

Drupal ist ein wichtiger Akteur, wenn es um den Aufbau von Websites und die Verwaltung ihrer Inhalte geht. Da die Entkopplung von Drupal immer beliebter wird, ist es wichtig geworden, zu verstehen, wie die APIs zusammen mit Drupal funktionieren. 

REST 

Apropos Installation und Konfiguration von REST, es kann bestenfalls kompliziert sein. Die Tatsache, dass das REST-Modul vom REST-UI-Modul begleitet werden muss, erleichtert die Komplexität nicht. 

Mit REST können die Clients, die keine Abfragen mit den benötigten Filtern selbst erstellen können, da das REST-Modul keine Client-generierten Sammlungsabfragen unterstützt. Dies wird oft als entkoppelte Filterung bezeichnet. 

JSON:API 

Das JSON:API-Modul landete in Drupal Core in Drupal 8.7. Die Konfiguration von JSON:API ist kinderleicht, es gibt einfach nichts zu konfigurieren. JSON ist in diesem Aspekt ein klarer Gewinner. 

In Bezug auf Client-generierte Abfragen bietet JSON seinen Clients diesen Luxus. Sie können ihre eigenen Inhaltsabfragen generieren und benötigen dafür keine serverseitige Konfiguration. Die Fähigkeit von JSON, die von Drupal angebotenen Zugriffskontrollmechanismen zu verwalten, erleichtert das Ändern einer eingehenden Abfrage. Dies ist eine Standardfunktion in JSON:API.

GraphQL 

Die Installation von GraphQL ist auch nicht so kompliziert wie REST, aber es ist auch nicht so einfach wie JSON. Dies liegt daran, dass es ein gewisses Maß an Konfiguration von Ihnen erfordert. 

Ähnlich wie JSON bietet GraphQL auch eine entkoppelte Filterung mit Client-generierten Abfragen. Ein weniger verbreiteter Trend bei GraphQL-Projekten ist das Einholen von Berechtigungen für persistierte Abfragen über Client-generierte Abfragen; was eine Rückkehr zum herkömmlichen Views-ähnlichen Muster mit sich bringt.

Zusätzlich zu diesen drei wichtigen Drupal-Webdiensten sollten Sie andere Alternativen im entkoppelten Drupal-Ökosystem erkunden, die einen Versuch wert sind. Lesen Sie alles über entkoppeltes Drupal, die architektonischen Unterschiede zwischen Headless- und traditionellen Setups, verschiedene Möglichkeiten, Drupal zu entkoppeln, und die Fähigkeiten, die zum Erstellen einer entkoppelten Drupal-Webanwendung erforderlich sind, um mehr zu erfahren.

Abschließend mit den Grundlagen 

Fassen wir zusammen und betrachten wir die grundlegende Natur der drei APIs, die zwei Aspekte umfasst: Einfachheit und Funktionalität. 

In Bezug auf die Einfachheit ist REST ein Gewinner. Ein zweiter würde an JSON vergeben, während GraphQL nicht als einfach beschrieben werden könnte und sollte, komplex und das auch immens mit großen Implementierungen, die auf Sie zukommen, wäre eine genauere Beschreibung. In Bezug auf die Funktionalität bietet GraphQL das meiste. Wenn Sie JSON gegenüber GraphQL wählen, würden Sie am Ende einige seiner Funktionen aufgeben, die in JSON nicht zu finden sind. 

Alle drei sind leistungsstark und effizient in dem, was sie für Ihre Anwendung tun können. Die Frage ist, wie viel Komplexität sind Sie bereit, mit dieser Leistung auf sich zu nehmen?