GraphQL vs REST: Überblick

Vor ein paar Monaten habe ich einen Vergleich zwischen RPC und REST für das Smashing Magazine geschrieben, und jetzt möchte ich über die Unterschiede zwischen REST und GraphQL sprechen: das neue Kind im Block.

GraphQL wird von manchen fälschlicherweise als "Ersatz" für REST angesehen. GraphQL ist ein neueres Konzept, das 2015 von Facebook veröffentlicht wurde, während REST eine von Roy Fielding im Jahr 2000 veröffentlichte Dissertation war, die 2006 von Unternehmen wie Twitter (ziemlich ungenau) populär gemacht wurde.

In diesem Artikel sollen einige bemerkenswerte Unterschiede behandelt und die folgenden Punkte hervorgehoben werden:

  1. REST und GraphQL sind völlig unterschiedlich
  2. GraphQL ist kein Wundermittel und auch nicht "besser"
  3. Sie können definitiv beide gleichzeitig verwenden
  4. GraphQL ist Dope, wenn es für das Richtige verwendet wird

REST ist ein Architekturkonzept für netzwerkbasierte Software, verfügt über keine offiziellen Tools, hat keine Spezifikation, kümmert sich nicht darum, ob Sie HTTP, AMQP usw. verwenden, und dient dazu, eine API vom Client zu entkoppeln. Der Fokus liegt darauf, APIs jahrzehntelang haltbar zu machen, anstatt sie für die Leistung zu optimieren.

GraphQL ist eine Abfragesprache, -spezifikation und -sammlung von Tools, die für den Betrieb über einen einzelnen Endpunkt via HTTP entwickelt wurden und hinsichtlich Leistung und Flexibilität optimiert wurden.

Einer der Hauptmandanten von REST ist die Verwendung der einheitlichen Schnittstelle der Protokolle, in denen es existiert. Bei der Verwendung von HTTP kann REST HTTP-Inhaltstypen, Caching, Statuscodes usw. nutzen, während GraphQL seine eigenen Konventionen erfindet.

Ein weiterer Schwerpunkt von REST sind Hypermedia-Steuerelemente (a.k.a. HATEOAS), mit denen ein gut gestalteter Client eine API wie ein Mensch im Internet ausführen kann. Beginnen Sie mit der Suche nach „Wie fülle ich meine Steuererklärungen aus?“, lesen Sie einen relevanten Artikel und lesen Sie nach ein paar Klicks den BuzzFeed-Artikel über Miley Cyrus, der Liam Hemsworth eine Geburtstagsfeier mit dem Thema „Unkraut“ veranstaltet.

Wenn Ihre API keine Hypermedia-Steuerelemente verwendet, ist GraphQL möglicherweise ein relevanterer Ansatz, da Sie REST ohnehin nicht wirklich verwendet haben.

In diesem Artikel wird nicht versucht, einen Gewinner zu ermitteln. Wir werden uns jedoch einige Bereiche ansehen, in denen sich die beiden unterscheiden. Seien Sie nicht böse, dass in vielen Abschnitten "es kommt darauf an" steht, denn der Gewinner in jedem Abschnitt hängt wirklich davon ab, was Ihre API tut und wie. GraphQL ist in einigen Bereichen stärker, REST in anderen, und manchmal sind beide irgendwie schrecklich. Lass uns reingehen!

Eine der häufigsten Aufgaben, die REST-APIs bereitstellen, ist CRUD über JSON, kann aber noch viel mehr, z. B. das Hochladen von Dateien.

Das Hochladen eines Bildes im HTTP-Body kann ungefähr so ​​aussehen:

POST / Avatare HTTP / 1.1
Gastgeber: localhost: 3000
Inhaltstyp: Bild / JPEG
Inhaltslänge: 284
Rohbildinhalt

Mit einem coolen Teil von HTTP (und damit REST) ​​können API-Entwickler Anwendungs- / JSON-Anforderungen auf demselben Endpunkt unterstützen, um den Upload etwas anders zu handhaben, und auch URL-basierte Uploads anbieten:

POST / Avatare HTTP / 1.1
Gastgeber: localhost: 3000
Inhaltstyp: Anwendung / json
{
  "image_url": "https://example.org/pic.png"
}

Im Allgemeinen haben die APIs, an denen ich gearbeitet habe, beide Vorteile. Dies ist sehr praktisch, da iOS häufig Fotos direkt aus lokalen Dateien sendet und Web-Clients häufig eine URL zum Facebook-Anzeigebild des Benutzers senden.

Wenn wir über das Hochladen von Videos oder anderen großen Dateien sprechen, würde ich (wie in diesem Artikel vorgeschlagen) auf einen anderen Ansatz umsteigen und über einen dedizierten Dienst verfügen, der den Upload übernimmt, sodass die Haupt-API nur Metadaten akzeptiert. Titel, Beschreibung, Tags usw.

Dies ist der Ansatz, den Sie mit GraphQL verfolgen müssen, da Sie mit GraphQL nur in Bezug auf Felder sprechen können:

POST / graphql HTTP / 1.1
Gastgeber: localhost: 3000
Inhaltstyp: application / graphql
Mutation addAvatar {
  addAvatarFromUrl (image_url: "https://example.org/pic.png") {
    Ich würde,
    Bild URL
  }
}

Einige werden argumentieren, dass dies "sauberer" und es ist, es ist sehr sauber, aber die Notwendigkeit, einen anderen Dienst zu erstellen, ist für kleinere Bilder besonders früh zu viel des Guten. Ein anderer Ansatz ist das direkte Hochladen auf Amazon S3, wodurch eine Abhängigkeit von Clients erzwungen wird und möglicherweise Token verloren gehen. Alternativ können Sie auch mehrteilige Uploads verwenden. Dies ist ein äußerst hackiger Ansatz, der davon abhängt, ob der Server und verschiedene Clients ihn überhaupt unterstützen können.

Dies ist ein Bereich, in dem REST stark ist. Einige würden sagen, dass der REST-Umgang mit CRUD und beliebigen Inhalten verwirrend ist, aber dies ist ein Kernmandant dessen, was REST so nützlich macht. Eine REST-API kann alles, nicht nur Felder vor- und zurücksenden - auch wenn REST so häufig verwendet wird.

Ein falsch beworbener Vorteil von GraphQL ist, dass Sie "nie etwas versionieren müssen".

Der vorgeschlagene Ansatz besteht darin, neue Felder hinzuzufügen und alte zu verwerfen. Dieses Konzept ist in REST als Evolution bekannt.

Genau das tun viele REST-APIs seit jeher, wenn sie es ablehnen, mit Dritten kommunizieren, die Nutzung überwachen und zu einem akzeptablen Zeitpunkt entfernen.

Bei REST geht es um Evolvabilität, also beschuldigen Sie es nicht für die schlechten Gewohnheiten der RESTish-Leute.

Obwohl GraphQL und REST über Evolution genauso einfach versionieren können (und sollten), hilft GraphQL API-Entwicklern wirklich, wenn es um Abwertungen geht.

Ein Bereich, in dem sich GraphQL auszeichnet, besteht darin, die Überwachung der Feldnutzung auf technischer Ebene unglaublich einfach zu gestalten. GraphQL-Clients müssen die Felder angeben, die in der Abfrage zurückgegeben werden sollen:

POST / graphql HTTP / 1.1
Gastgeber: localhost: 3000
Inhaltstyp: application / graphql
{
  Schildkröten (id: "123") {
    Länge,
    Breite,
    Intelligenz
  }
}

Dies nachzuverfolgen wäre trivial, aber eine REST-API verhält sich etwas anders. Während alle REST-APIs den Basisendpunkt über / turtles / 123 zur Verfügung stellen, bieten nicht alle APIs spärliche Feldmengen: / turtles / 123? Fields = length, width, intelligence. Von denen, die es anbieten, ist es fast immer optional.

Wenn ein REST-API-Client / turtles / 123 aufruft, verwendet er möglicherweise ein beliebiges Feld in dieser Antwort. Stellen Sie sich vor, die API plant, Informationen loszuwerden (weil alle Schildkröten Genies sind). Woher wissen die API-Entwickler, welche Clients dieses Feld verwenden?

Bei einem RPC-Ansatz wird ein neuer / getTurtle2-Endpunkt (oder / v2 / turtles / 123 in einer RPC-API, die vorgibt, eine REST-API zu sein) erstellt und die Benutzer angewiesen, diesen neuen Endpunkt zu verwenden.

Ein Ansatz in REST-APIs besteht darin, Warnungen per E-Mail an die E-Mail-Adresse zu senden, die bei der Registrierung des Clients für OAuth-Token (wie zuvor bei Facebook) eingegeben wurde, und möglicherweise ein Feature-Flag anzubieten, damit verschiedene Clients den Schalter umlegen können, wenn sie bereit sind.

Ein anderer Ansatz wäre, eine neue Version der Ressource zu erstellen. Dies bedeutet, dass GET nicht mit Accept: application / vnd.turtlefans.com + v1 + json aufgerufen wird, sondern mit Accept: application / vnd.turtlefans.com + v2 + json .

Alle oben genannten Ansätze weisen das gleiche Problem auf, und das heißt, dass eine gesamte Version bei einer einfachen Änderung überflüssig werden kann und Sie die Entwickler möglicherweise dazu zwingen, ein Versions-Upgrade in Betracht zu ziehen, ohne dass dies erforderlich ist.

Wenn der Client beispielsweise application / vnd.turtlefans.com + v1 + json anfordert und die API Informationen in Version 2 entfernt, müssen die API-Entwickler Version 1 erst löschen, wenn das letzte Upgrade der Clients durchgeführt wurde. Leider haben die API-Entwickler keine Ahnung, ob Clients v1 aufrufen, aber nicht das Intelligence-Feld verwenden. Die API-Entwickler wissen nur, dass die Clients v1 möchten und nicht, was sie von dieser Ressource v1 verwenden.

Mit GraphQL ist es einfach, die Verwendung bestimmter Felder für einen Client zu verfolgen. Dies bedeutet, dass API-Besitzer nur die Clients erreichen können, die Felder verwenden, die auf dem Weg sind, oder bei internen Projekten können Fehler in Entwicklungs- / Staging-Umgebungen auftreten.

Ich hatte ein vages Hirngespinst damit, diese letztere Option für Nicht-GraphQL-HTTP-APIs zu machen, aber ich hatte noch keine Chance, sie durchzuhalten.

https://twitter.com/philsturgeon/status/631588563524694016

Das könnte in manchen Situationen hilfreich sein, würde sich aber sicherlich auf die gleiche Weise wie in GraphQL auswirken.

Mit GraphQL wurde ich von Tom Clark, superschlauer Head of Devops bei WeWork, darauf aufmerksam gemacht, dass die Abschreibung von Feldern einfacher ist.

GraphQL ist immer die kleinstmögliche Anforderung, während REST im Allgemeinen die vollständigste ist. Es ist üblich, Optionen wie? Fields = foo, bar oder partials anzubieten. Google empfiehlt dies für HTTP-APIs, unabhängig davon, was das wert ist.

Selbst wenn eine REST-API standardmäßig nur einen einfachen Teil zurückgibt, werden standardmäßig immer noch mehr Bits über die Leitung übertragen als mit dem GraphQL-Ansatz. Wenn ein Client ein Feld benötigt, fordert er es an, und wenn die API ein neues Feld hinzufügt, erhalten Clients es nicht, es sei denn, sie entdecken dieses Feld in einem Blog-Beitrag oder einem anderen Artikel und fügen es der GraphQL-Abfrage hinzu.

Das Zwischenspeichern für HTTP, die allgemeine Verwendung in REST-APIs und verschiedene Arten des Zwischenspeicherns sind wichtige Themen, die ich aus diesem Artikel herauslösen musste. Ich werde in Kürze ein Follow-up veröffentlichen, das auf dem APIs You Won't Hate Newsletter veröffentlicht wird.

In einer endpunktbasierten API können Clients HTTP-Caching verwenden, um das erneute Abrufen von Ressourcen zu vermeiden und um festzustellen, ob zwei Ressourcen identisch sind. Die URL in diesen APIs ist eine global eindeutige Kennung, mit der der Client einen Cache erstellen kann.
In GraphQL gibt es jedoch kein URL-ähnliches Grundelement, das diesen global eindeutigen Bezeichner für ein bestimmtes Objekt bereitstellt. Es ist daher eine bewährte Methode für die API, einen solchen Bezeichner für die Verwendung durch Clients bereitzustellen.
- Quelle: graphql.org

REST über HTTP verwendet eine ganze Reihe von HTTP-Konventionen, mit denen vorhandene HTTP-Clients, HTTP-Cache-Proxys usw. problemlos funktionieren, um sowohl API-Clients als auch API-Server zu unterstützen, aber mit GraphQL ... ist dies schwierig. Ordnen Sie Ihre Datenspeicher neu an, verwenden Sie eine Reihe von Redis und hoffen Sie, dass auch Clients zwischengespeichert werden.

Ein sehr grundlegender Unterschied hierbei ist natürlich, dass nur eine davon eine Abfragesprache ist. REST-APIs werden häufig zunächst einfach erstellt, dann werden im Laufe der Zeit langsam mehr und mehr abfragesprachenähnliche Funktionen verwendet.

Die vernünftigste Möglichkeit, Argumente für Abfragen in REST bereitzustellen, besteht darin, sie in die Abfragezeichenfolge zu verschieben. Vielleicht ein? Status = active, um nach Status zu filtern, dann wahrscheinlich sort = created, aber ein Client benötigt Sortierrichtung, damit sort-dir = desc hinzugefügt wird.

Einige APIs verwenden auch Argumente in der Abfragezeichenfolge, die sich nicht auf das Filtern beziehen, sondern eher auf Optionen. Im GraphQL-Beispiel geben sie die Einheit an, in der eine Höhe zurückgegeben werden soll:

{
  Mensch (ID: "1000") {
    Name
    Höhe (Einheit: Fuß)
  }
}

Das ist verdammt praktisch und verhindert die Verwechslung von "Status = Aktiv" als Filter, "Einheit = Fuß" als Anzeigeoption. Ich habe "filter: status = active", "filter [status] = active" usw. gesehen, aber das ist immer noch ein bisschen chaotisch.

In diesen Szenarien schlägt GraphQL die Hosen von REST-APIs, die versuchen, ihre eigene Abfragesprachenfunktionalität von Hand zu rollen, aber ich würde vorschlagen, dass es sowieso eine schlechte Idee ist, Ihre eigene Abfragesprache von Hand zu rollen. In GraphQL gibt es eine Abfragesprachensyntax und SDKs für Ihre Programmiersprache, mit denen Sie die richtigen Modelle dafür abrufen können, aber auch OData, ein Projekt mit dem Slogan „A Better Way to REST“.

Dies ist ein weiteres Beispiel dafür, dass Leute sagen, dass REST etwas nicht kann, nur weil viele REST-APIs es nicht tun oder weil es von vielen, die es tun, schlecht implementiert wird. Denken Sie jedoch daran, dass je mehr Anpassungen eine endpunktbasierte API der Anforderung hinzufügt, desto weniger Cache-Treffer auf Netzwerk-Caching-Ebene wahrscheinlich sind, was den REST / HTTP-Ansatz weniger lohnend macht und Sie dazu zwingt, die Route für das Anwendungs-Caching und zu verkürzen Datenbank-Reorganisation, die GraphQL sowieso erzwingt.

Wenn Ihre API in hohem Maße anpassbar ist, ist dies ein weiteres Kontrollkästchen für die Berücksichtigung von GraphQL.

Ein weiterer wichtiger Aspekt bei der Anpassung ist, wann Sie eingeschlossene Beziehungen anbieten und wann Sie einen anderen Endpunkt verwenden. Dies kann eine schwierige Design-Wahl sein, da Sie möchten, dass Ihre API flexibel und performant ist, aber die Verwendung von Inhalten, die über die trivialsten Verwendungen hinaus verwendet wurden, kann das Gegenteil davon sein.

Sie beginnen mit zu simplen Beispielen wie / users? Include = comments, posts, landen aber auf /trips?include=driver,passengers,passengers.avatar, passengers.itineraries und schlechter.

Ich nenne dies das "Mega Include von DOOOOOOM", und es ist eine beschissene Lösung für ein echtes Problem, wenn Kunden Leistung über alles andere streben. Includes sind eine gängige Konvention in REST-APIs, die in Spezifikationen wie der JSON-API empfohlen wird, die REST-Regeln jedoch ein wenig verbiegt.

REST würde nach einem HATEOAS-Ansatz verlangen, bei dem Sie einen Anruf beim / trips-Endpunkt tätigen und dann auf "links": {"driver": "https://example.com/drivers/123"} und erneut auf Passagiere, und wieder für Kinderdaten von jedem dieser Passagiere. In diesem Fall wäre es schlimmer als das gefürchtete n + 1 und eher wie n + (2+ (num Passagiere * 2))!

Einschließlich Start mit den besten Absichten, kann jedoch zu einem Engpass in einer REST-API werden, da unhandliche Abfragen für den Datenspeicher ausgeführt werden. GraphQL entfernt nicht nur diese Entwurfsfrage, sondern erzwingt auch den Einschlussansatz und zwingt Sie, effiziente Mittel zum Abrufen dieser Daten in Betracht zu ziehen.

Dies ist ein großer Gewinn für GraphQL, da GraphQL den Einschluss-Ansatz forciert und effiziente „Mega Includes of Doom“ erzwingt. Dies wird sowohl effizient als auch konsistent sein. Der Versuch, eine REST-API als Nur-Include-API zu definieren, wäre bizarr und unbrauchbar, sodass die Konsistenz dort niemals funktioniert.

GraphQL hilft bei Ihren Datenbankabfragen nicht weiter, daher müssen Sie diese Indizes noch optimieren und Fragmente der Daten intelligent zwischenspeichern. Wenn Sie dies überspringen, werden Sie die Kunden überraschen. Bei einem früheren Job hatten wir ein schlecht abgestimmtes Mega-Include von der iOS-App, für dessen Beantwortung ungefähr 20s + benötigt wurden, was verdammt furchterregend war. Wir haben sie fast nur dazu gebracht, eine neueste .sqlite für die lokale Verarbeitung einzurollen.

Bei erneuter Verwendung dieses Reisebeispiels kann ein Kunde Passagiere einschließen, erkennt jedoch, dass dies historische Passagiere einschließt. Möchten Sie keine Personen sehen, die die Fahrgemeinschaft verlassen haben? Der Kunde muss die Passagiere lokal durchlaufen und alle Modelle entfernen, bei denen model.status! = "Active" ist, was eine Verschwendung der Verarbeitung auf Kundenseite darstellt.

Der REST-Weg, dies zu tun, wäre / passenger? Trip = 123 & status = active, was offensichtlich flexibler ist, aber Kunden werden dies aufgrund der zusätzlichen Anforderungen überspringen.

Da die clientseitige Filterung eine schlechte Wahl ist und die zusätzliche Anforderung nicht ideal ist, müssen REST-API-Entwickler häufig ein neues Include hinzufügen: / trips? Include = activePassengers. Diese sind schwer vorwegzunehmen, daher hatte ich die Hoffnung, dass GraphQL den Kunden dabei helfen kann, ihre eigenen Bereiche zu definieren, und diese Includes so filtern, dass sie die entsprechenden Daten selbst darstellen. Dies würde dazu beitragen, die umfassten Includes zu identifizieren, die die API als bequeme Methoden hinzufügen sollte.

Es scheint, als würde GraphQL API-Entwicklern in diesem Fall nicht weiterhelfen, aber es scheint zu sprechen, @filter hinzuzufügen, um dies in Zukunft zu tun.

Eine weitere für REST-API-Entwickler häufig gestellte Frage lautet:

Unsere iOS-App, Android-App und Web-App unterscheiden sich stark voneinander. Wie würden wir für jeden Kunden unterschiedliche Daten zurückgeben?

Wir alle beginnen mit dem Versuch, unsere REST-APIs so allgemein zu gestalten, dass sie von allen verwendet werden können. Da das Mega-Include-Problem jedoch angezeigt wird, möchten und benötigen Kunden viel und versuchen immer, die Anzahl der Aufrufe zu reduzieren.

Einige grundlegende Lösungen für die Ausgabe verschiedener Daten pro Client in einer REST-API sind:

Erstellen Sie benutzerdefinierte Endpunkte: / iphone_snapshot. Wir haben dies in einer früheren Firma gemacht, in der sich die mobilen Daten von allem anderen unterschieden. Es fühlte sich schmutzig an, war definitiv RPC, aber es hat die Arbeit erledigt. Wenn die angeblich generische REST-API so viel über einen bestimmten Client weiß, wird der Zweck ein wenig zunichte gemacht, aber wir mussten die Daten auf das iPhone übertragen, und genau das geschah.

Benutzerdefinierte Darstellungen erstellen: Mit Content-Type: application / vnd.turtlefans.com + v1 + iphone + json, das einen eigenen benutzerdefinierten Serializer hatte, wäre angeblich ein bisschen mehr REST, da es nur eine andere Darstellung ist, aber genauso seltsam.

Benutzerdefinierte APIs! Dieses Konzept wurde / wird von Netflix verwendet, wenn ich mich recht erinnere, und die Idee ist, eine API für jeden ihrer Kunden zu haben. Es gibt eine Android-REST-API, eine iOS-REST-API, eine Web-REST-API usw. Jede dieser APIs ist perfekt auf die Anforderungen der jeweiligen Teams zugeschnitten und sendet Anfragen an die zentrale generische REST-API. Das Erfordernis mehrerer APIs, mehrerer Entwicklungsteams usw. ist sicherlich für viele Unternehmen unerreichbar, löst das Problem jedoch auf angenehme Weise.

Oder… GraphQL! Anstatt benutzerdefinierte Endpunkte, benutzerdefinierte Darstellungen oder benutzerdefinierte APIs zu erstellen, schreiben die Clients einfach ihre eigenen Abfragen. Dies verlagert die Verantwortung von den API-Entwicklern auf die Kunden, die dann in der Sprache ihrer Wahl schreiben können, anstatt das API-Team dazu zu bringen, diese in einer anderen Sprache zu schreiben.

Ob Sie diesen Paradigmenwechsel brauchen oder nicht, hängt ganz davon ab, wie ähnlich Ihre Kunden sind. Wenn Sie eine private / interne API sind und Ihre Kunden praktisch alle identisch sind, möchten Sie mit Sicherheit nicht, dass sie alle mit den Dingen umgehen.

Wenn Sie jedoch eine Vielzahl unterschiedlicher Clients haben oder öffentlich sind (daher keine Ahnung haben, wie die API verwendet wird), wird GraphQL schnell ansprechender.

Die größte Seltsamkeit, die ich im Gespräch „GraphQL vs REST“ bemerke, ist die Lüge, die Sie auswählen müssen.

In einer Welt von SoA verfügen Sie wahrscheinlich über mehrere Services, die mehrere APIs verfügbar machen. In dem Artikel RPC vs REST weise ich darauf hin, dass einige Dienste REST und andere RPC sein können und Sie absolut GraphQL in Ihr REST einbinden können.

Eine Mischung aus REST und GraphQL könnte darin bestehen, api.whatever.com einen / graphql-Endpunkt hinzuzufügen und diesen als GraphQL-Endpunkt in einer REST-API zu verwenden.

Eine andere, die bei der Arbeit vage herumgeworfen wurde, ist die Idee, eine GraphQL-API zu haben, die als Gateway zu unseren anderen mehreren REST-APIs fungiert.

Ein GraphQL-Server fungiert als eine Art Daten-Proxy, der einen Einstiegspunkt für gemischte Daten, ein Authentifizierungsschema bietet, obwohl jede REST-API einen eigenen „eindeutigen“ Ansatz für Token hat, und einen HTTP-Aufruf für Clients, obwohl mehrere tatsächliche REST-APIs vorhanden sind usw. wäre eine verdammt mächtige Sache.

Stellen Sie sich - zumindest - die folgenden Fragen:

  • Wie unterschiedlich sind Ihre Kunden voneinander?
  • Vertrauen Sie Ihren Kunden, dass sie mit dem Caching umgehen?
  • Möchten Sie "dumme Clients", die sich wie Crawler verhalten und nur wenig über die API wissen, oder Clients, die einen Großteil der Logik besitzen und viel über die API wissen und diese einfach als Datenübertragung verwenden?
  • Sind Sie in der Lage, HTTP-Debugging-Proxys, Cache-Proxys und all das Wissen, das Ihr Team über HTTP usw. hat, loszulassen?
  • Tun Sie einfach nur einfaches CRUD mit einfachen JSON-Dokumenten, oder muss Ihre API auch Dateien hochladen / herunterladen?

Wenn Ihre REST-API bewährten Methoden folgt, z. B. sorgfältige Weiterentwicklung statt globaler Versionierung, Serialisierung von Daten statt Rückgabe direkt aus dem Datenspeicher, Implementierung spärlicher Feldsätze, um die Antwortgrößen zu verringern, GZiping-Inhalte, Skizzieren von Datenstrukturen mit JSON-Schema und Binary Alternativen zu JSON wie Protobuff oder BSON usw., dann scheinen die angekündigten Vorteile von GraphQL etwas zu kurz zu kommen.

Wenn Sie eine API mit hoher Abfragemöglichkeit benötigen, eine Reihe von Clients erwarten, die kleine und unterschiedliche Daten benötigen, und Ihre Daten so umstrukturieren können, dass sie kostengünstig abgefragt werden können, ist es wahrscheinlich, dass GraphQL Ihren Anforderungen entspricht.

Abgesehen von diesen verschiedenen oben aufgeführten Vor- und Nachteilen für GraphQL ist es für mich eine echte Freude, wenn GraphQL eine Option darstellt, eine neue Alternative zu REST zu haben, wenn eine API in Betracht gezogen wird. Eine gut dokumentierte Alternative mit vollständiger Spezifikation, einer ansprechenden Marketing-Seite, einer offiziellen Referenzimplementierung in JavaScript, die einige der kniffligen Design-Entscheidungen vermeidet, zu denen REST Sie zwingt.

Ich mag, dass viele Leute REST nicht mehr wie ein glänzendes Einhorn behandeln, sich bemühen, REST richtig zu implementieren, und es dann REST nennen, nur damit sie gut aussehen und ein für ihr Marketing haben. Ich hoffe nur, dass nicht zu viele Leute GraphQL stattdessen wie ein glänzendes Einhorn behandeln.

Das Austauschen eines falschen Idols gegen ein anderes wird die API-Welt nicht verbessern.

Ursprünglich veröffentlicht bei philsturgeon.uk am 24. Januar 2017.