GraphQL vs REST

Was ist der Unterschied zwischen GraphQL und REST?

GraphQL und REST sind zwei Ansätze, eine API zu bauen, die Schicht, über die ein Frontend ein Backend nach Daten fragt. REST organisiert alles um Ressourcen, jede mit eigener URL. Sie holen einen Nutzer von einem Endpunkt, seine Bestellungen von einem anderen, die Artikel jeder Bestellung von einem dritten. GraphQL stellt einen einzigen Endpunkt und ein Schema bereit, und der Client schickt eine Abfrage, die genau die gewünschten Daten beschreibt, und bekommt diese Form zurück und nichts sonst.

Der Unterschied zeigt sich am deutlichsten bei zwei Problemen, zu denen REST neigt. Over-Fetching ist, wenn ein Endpunkt mehr Felder liefert, als Sie brauchen. Under-Fetching ist, wenn ein Aufruf nicht reicht und Sie mehrere machen müssen, um eine Ansicht zusammenzusetzen. Eine mobile Profilseite in REST ruft vielleicht drei Endpunkte auf und wirft die Hälfte des Zurückgelieferten weg. Dieselbe Seite in GraphQL ist eine Abfrage, die genau die Felder liefert, die die Ansicht rendert, weshalb bandbreitenbewusste Apps sie oft bevorzugen.

Keiner gewinnt rundheraus. REST ist einfacher, stützt sich auf das HTTP-Caching, das das gesamte Web bereits versteht, und ist bei geradlinigem Ressourcenzugriff leicht nachzuvollziehen. GraphQL gibt Clients Flexibilität und reduziert Roundtrips, verschiebt aber Komplexität auf den Server, erschwert das Caching und verlangt Sorgfalt bei den Abfragekosten, damit eine einzelne Anfrage nicht zu viel verlangen kann. Die richtige Wahl hängt vom Client, von der Form der Daten und davon ab, wer die API nutzt.

GraphQL und REST bei Dallonses

Wir haben keinen Haus-Favoriten. Wir wählen nach dem Problem. Ein Kunde, der eine Content-Plattform mit vielen Client-Typen und tief verschachtelten Daten baute, bekam GraphQL, weil die Flexibilität ihren Aufwand wirklich aufwog und seine Frontend-Teams vorankamen, ohne auf neue Endpunkte zu warten. Ein anderer Kunde brauchte eine saubere, cachebare öffentliche API für Partner, und REST war die offensichtliche, ehrliche Antwort. GraphQL dort zu erzwingen hätte Komplexität für nichts hinzugefügt.

Beide Entscheidungen gehören dazu, wie wir API-First-Entwicklung angehen. Wir wählen den Stil, bevor wir den Vertrag schreiben, wägen mit dem Kunden die Folgen für Caching und Tooling ab und legen uns auf einen fest, statt einen zweiten anzuschrauben, um eine schlechte erste Entscheidung zu übertünchen. Das Ziel ist eine API, mit der die eigenen Entwickler des Kunden jahrelang leben können, nicht die, die sich in einem Pitch am besten liest.

Entscheiden Sie sich zwischen GraphQL und REST für eine neue API? Wählen wir die passende.

Sprechen Sie mit uns über API-Design