"REST Vs GraphQL" ist es ein korrekter Vergleich?

Ich habe auf vielen Websites gesehen, dass REST mit GraphQL verglichen wird. Nachdem ich dieses Anliegen (eigentlich mein Anliegen) untersucht habe, dass "es ein korrekter Vergleich ist?", bin ich verwirrter. Da der REST eine andere Definition als GraphQL hat, beschäftigt mich diese Frage damit, warum wir zwei verschiedene Konzepte miteinander vergleichen können.

Eigentlich scheint mir der Vergleich so etwas zu sein:

IDE Vs Compiler! ??! oder BMW x6 gegen ISO 18541-5 (Straßenfahrzeuge)

aus dem Wiki:

Rest Definition:

Representational State Transfer (REST) ist ein Softwarearchitekturstil, der eine Reihe von Einschränkungen definiert, die zum Erstellen von Webdiensten verwendet werden sollen.

GraphQl-Definition:

GraphQL ist eine Open-Source-Sprache für Datenabfragen und -manipulationen für APIs und eine Laufzeit für die Erfüllung von Abfragen mit vorhandenen Daten.

Bitte erhellen Sie meine Gedanken mit Ihren Antworten. Vielen Dank

REST ist ein Architekturstil, der in den 1990er Jahren parallel zum World Wide Web entwickelt wurde.

Das World Wide Web ist eine Referenzanwendung für den REST-Architekturstil (mit einigen Abweichungen ).

HTTP ist ein Anwendungsprotokoll zum Übertragen von Dokumenten über ein Netzwerk.

GraphQL ist eine Abfragesprache und eine Ausführungsmaschine .

Sie haben Recht, dass der direkte Vergleich von REST und GraphQL ein Chaos ist. Sie können sich jedoch die Art der Probleme, die sie zu lösen versuchten, genau ansehen.

Durch die Anwendung des allgemeinen Software-Engineering-Prinzips auf die Komponentenschnittstelle wird die Gesamtsystemarchitektur vereinfacht und die Sichtbarkeit von Interaktionen verbessert. Implementierungen sind von den von ihnen angebotenen Diensten entkoppelt, was eine unabhängige Evolvabilität fördert. Der Nachteil ist jedoch, dass eine einheitliche Schnittstelle die Effizienz beeinträchtigt, da Informationen in einer standardisierten Form übertragen werden und nicht in einer Form, die spezifisch für die Anforderungen einer Anwendung ist. Die REST-Schnittstelle ist so konzipiert, dass sie für die Übertragung von Hypermedia-Daten mit großen Körnern effizient ist und für den allgemeinen Fall des Web optimiert ist. Dies führt jedoch zu einer Schnittstelle, die für andere Formen der architektonischen Interaktion nicht optimal ist. Fielding, 2000

In REST ist das Caching eine große Sache, und die aktuelle HTTP-Spezifikation enthält einen gesamten RFC , der der Caching-Semantik gewidmet ist. Aber Leute, die GraphQL verwenden, haben anscheinend entschieden, dass das Caching für ihr Problem nicht von Bedeutung ist.

Wie ich am besten beurteilen kann, trifft GraphQL viele der gleichen Kopplungsoptionen wie SOAP . Das ist nicht richtig oder falsch - nur eine andere Abwägung der Kompromisse.

Nein, dieser Vergleich ist ungültig.

Wie Sie gesagt haben, sind GraphQL und REST verschiedene Dinge, also ist es wie ein Vergleich von Äpfeln und Orangen.

Das ist eine Ansicht / Perspektive dieses Problems. Das zweite ist genau das Gegenteil - GraphQL / REST-Vergleiche sind gültig und sehr nützlich .

Um diese zweite Sichtweise zu verstehen, müssen wir folgende Frage stellen:

Wie kann ich meine Daten an Kunden liefern? Welche soll ich nehmen ...?

Die Antwort auf die erste Frage enthält sowohl REST als auch GraphQL (mit vielen anderen Möglichkeiten). Beide sind nützlich, um Daten an Clients zu liefern (Lesen - Erstellen von APIs). Die zweite Frage ist tatsächlich die, die hinter all den Vergleichen steht, die Sie gelesen haben.

Der Vergleich verschiedener Arten der Datenlieferung ist gültig und notwendig. Unter diesem Gesichtspunkt spielt es keine Rolle, dass die Art der verglichenen Dinge anders ist. Beide können die Arbeit erledigen, daher sollten Sie sie vergleichen.

Es ist wie ein Vergleich des Geschmacks von Äpfeln und Orangen - das können Sie tun.

Persönlich mache ich diesen Vergleich die ganze Zeit. Sehr nützlich, um Kollegen verschiedene Arten der Problemlösung beizubringen.