Editorial

Forget the REST?!

Dominik Mohilo


Man stelle sich den klassischen Besuch im Internet vor. Zunächst surft man bei Twitter vorbei, schaut sich ein paar Nachrichten und vielleicht sogar sogenannte Nachrichtenthreads an, vergibt hier und da ein paar Likes und retweetet das ein oder andere. Dann geht es weiter zum Onlineshop. Man sucht nach einem Artikel, lässt sich per Klick die teuerste Variante anzeigen, entscheidet sich dann doch für eine Sortierung nach Nutzerbewertung und wenige Eingaben später ist das Paket fast schon auf dem Weg zu uns. Zum Schluss noch ein Besuch auf einer Videoplattform der Wahl, bevor man den Rechner wieder herunterfährt.All diese Interaktionen zwischen dem Client (also dem Internetnutzer) und dem Server müssen in irgendeiner Weise kommuniziert werden – hier kommen heutzutage, neben den weit verbreiteten RESTful Web Services, immer häufiger auch Web-Service-Architekturen in Verbindung mit der Abfragesprache GraphQL zum Einsatz. Mit diesen wird die Datenstruktur auf Clientseite genau definiert und vom Server exakt zurückgegeben. Daten, die nicht gebraucht werden, werden weder vom Server angefordert noch zurückgegeben.Während also bei „klassischen“ REST Services das Backend entscheidet, welche Informationen aktuell zur Verfügung stehen, entscheidet bei GraphQL das Frontend. Das Egebnis ist eine flexiblere und effizientere Kommunikation zwischen Server und Client. Doch ist das wirklich der praktikablere und zukunftsweisendere Weg? Sind REST Services damit zum Untergang verdammt? Und ist das, was man landläufig als RESTful Web Service bezeichnet, auch wirklich REST?Im Interview mit Christian Schwendtner gehen wir diesen Fragen auf den Grund, während Robin Wieruch in seinem Artikel die Vor- und Nachteile der beiden Ansätze auf Herz und Nieren prüft. Michael Dähnert ergänzt unser Titelthema mit einer Anleitung zum Aufsetzen einer GraphQL-Architektur, Holger Tiemeyer, Paul Reiser, Fabian Volkert und Arne Koschel hingegen befassen sich in ihrem Artikel mit dem Erstellen von RESTful APIs.Am Ende kann sich jeder Entwickler hoffentlich selbst ein Bild davon machen, welcher der beiden Architekturansätze für die eigenen Anwendungen der richtige ist. Und ob es überhaupt nötig ist, sich für einen der beiden zu entscheiden. Dominik Mohilo, Redakteur

All diese Interaktionen zwischen dem Client (also dem Internetnutzer) und dem Server müssen in irgendeiner Weise kommuniziert werden – hier kommen heut...

Editorial

Forget the REST?!

Dominik Mohilo


Man stelle sich den klassischen Besuch im Internet vor. Zunächst surft man bei Twitter vorbei, schaut sich ein paar Nachrichten und vielleicht sogar sogenannte Nachrichtenthreads an, vergibt hier und da ein paar Likes und retweetet das ein oder andere. Dann geht es weiter zum Onlineshop. Man sucht nach einem Artikel, lässt sich per Klick die teuerste Variante anzeigen, entscheidet sich dann doch für eine Sortierung nach Nutzerbewertung und wenige Eingaben später ist das Paket fast schon auf dem Weg zu uns. Zum Schluss noch ein Besuch auf einer Videoplattform der Wahl, bevor man den Rechner wieder herunterfährt.All diese Interaktionen zwischen dem Client (also dem Internetnutzer) und dem Server müssen in irgendeiner Weise kommuniziert werden – hier kommen heutzutage, neben den weit verbreiteten RESTful Web Services, immer häufiger auch Web-Service-Architekturen in Verbindung mit der Abfragesprache GraphQL zum Einsatz. Mit diesen wird die Datenstruktur auf Clientseite genau definiert und vom Server exakt zurückgegeben. Daten, die nicht gebraucht werden, werden weder vom Server angefordert noch zurückgegeben.Während also bei „klassischen“ REST Services das Backend entscheidet, welche Informationen aktuell zur Verfügung stehen, entscheidet bei GraphQL das Frontend. Das Egebnis ist eine flexiblere und effizientere Kommunikation zwischen Server und Client. Doch ist das wirklich der praktikablere und zukunftsweisendere Weg? Sind REST Services damit zum Untergang verdammt? Und ist das, was man landläufig als RESTful Web Service bezeichnet, auch wirklich REST?Im Interview mit Christian Schwendtner gehen wir diesen Fragen auf den Grund, während Robin Wieruch in seinem Artikel die Vor- und Nachteile der beiden Ansätze auf Herz und Nieren prüft. Michael Dähnert ergänzt unser Titelthema mit einer Anleitung zum Aufsetzen einer GraphQL-Architektur, Holger Tiemeyer, Paul Reiser, Fabian Volkert und Arne Koschel hingegen befassen sich in ihrem Artikel mit dem Erstellen von RESTful APIs.Am Ende kann sich jeder Entwickler hoffentlich selbst ein Bild davon machen, welcher der beiden Architekturansätze für die eigenen Anwendungen der richtige ist. Und ob es überhaupt nötig ist, sich für einen der beiden zu entscheiden. Dominik Mohilo, Redakteur

All diese Interaktionen zwischen dem Client (also dem Internetnutzer) und dem Server müssen in irgendeiner Weise kommuniziert werden – hier kommen heut...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang