senäh

17senäh und so…

Allgemein
25. Okt 2013
Kommentare: 0

REST

Kategorien: Allgemein | 25. Okt 2013 | Kommentare: 0

Serie: Einführung in den MEAN Stack

Heute erwartet euch ein größtenteils theoretischer Artikel zum Thema REST und warum dieses Konzept so wichtig ist. Dieser Artikel wird die Grundlage für unsere spätere Server API sein.

REST bzw. eine RESTful API ist ein Konzept um Daten zwischen der Datenbank über einen Server mit einem Client mittels HTTP-Requests auszutauschen und zu manipulieren. Die Abkürzung REST steht dabei für Representational State Transfer. Zu diesem Zweck werden die Methodennamen von HTTP einer sogenannten CRUD-Funktionalität zugeordnet. Dies steht für Create, Read, Update und Delete und stellt die grundlegenden Operationen, die man auf Daten anwenden kann, dar. Die geforderten Daten werden über eine URL beschrieben, wobei jeweils eine URL für eine Collection von Daten und eine URL für einen einzelnen Datensatz aus dieser Collection existieren. (Hinweis: Auch wenn ich hier zur Erklärung des REST-Konzeptes Begriffe aus der NoSQL-Welt verwende, so kann REST auch mit klassischen SQL-Datenbanken verwendet werden.) Nicht alle CRUD-Befehle lassen sich aber auf diese URLs anwenden. Daraus ergibt sich folgendes Konzept:

HTTP Methode URL Collection: /{collection} URL Dokument: /{collection}/{id}
POST (Create) Erstellt ein neues Dokument für diese Collection.
GET (Read) Gibt mehrere Dokumente der Collection zurück. Gibt ein einzelnes Dokument zurück.
PUT (Update) Aktualisiert ein einzelnes Dokument.
DELETE (Remove) Löscht mehrere Dokumente in der Collection. Löscht ein einzelnes Dokument.

Mit diesem Konzept lassen sich auch Hierarchien abbilden. Angenommen wir besitzen jeweils eine Collection für Blogartikel und für Leserkommentare mit einer 1-zu-n-Beziehung (ein Artikel hat beliebig viele Kommentare). So könnte man mit der URL /articles/1/comments/2 den zweiten Kommentar des ersten Artikels adressieren. Über Query-Parameter ließen sich noch feinere Filter einstellen. Falls man alle Blogartikel von einem bestimmten Autoren aus den Jahren 2010 bis 2012 adressieren möchte, so könnte die entsprechende URL möglicherweise so aussehen: /articles?author=Pipo&from=2010&to=2012. Dies ist dabei nicht zwangsläufig die URL, die auch die Leser eures Blogs sehen und verwenden, sondern lediglich die URL, die der Client verwendet, um den entsprechenden Datensatz zu erhalten.

Dies ist eine sehr kurze Erklärung für das REST Konzept, welches aber für ein grundlegendes Verständnis ausreichen sollte. Die Idee von REST wurde von Roy Fielding in seiner Dissertation 2000 formuliert.

Nun könnte man sich die Frage stellen wozu wir REST überhaupt brauchen? Schließlich haben unsere vorigen Beispiele schon gezeigt, wie man Daten aus der Datenbank über den Server an den Client schickt. Es sprechen viele Gründe für REST: REST erlaubt nicht nur eine einfache Abfrage der Daten von der Datenbank zum Client, sondern auch die Manipulation dieser Daten – also der Weg in die andere Richtung. Da REST auf HTTP basiert ist es außerdem universell einsetzbar. Angenommen neben einer Webapplikation wollt ihr auch noch eine native App für iOS oder Android entwickeln. Mit REST könnt ihr sowohl für die Web- als auch native App den gleichen Server und die gleiche Datenbank einsetzen. Ihr müsst auf der Serverseite keine Codeänderungen für verschiedene Clients vornehmen. Als weiteren Grund erlaubt REST das einfache Nachladen von Daten und damit sehr viel dynamischere Oberflächen (Stichwort: AJAX). Schlussendlich ist REST eine leicht verständliche Schnittstelle. Die Beschränkung auf CRUD-Befehle begrenzt den Handlungsspielraum bei der Erstellung der API zwangsläufig und scheint damit zunächst hinderlich zu sein, aber auf der anderen Seite bleibt die API so übersichtlich und ähnelt auch APIs anderer Plattformen. Wer einmal eine REST API verwendet hat, wird sich bei anderen REST APIs auch schnell zurecht finden.

Nach diesem theoretischen Artikel wenden wir beim nächsten Mal das REST Konzept praktisch an!

Autor: Pipo

...kommt ursprünglich aus der Designerecke, ist aber im Laufe seines Studiums in die Webentwicklung gestolpert. Kann sich seit dem nicht so richtig entscheiden wo er hingehört und wagt deswegen vielleicht die Flucht nach vorne in ein komplett neues Gebiet. Vielleicht Management? Niemand weiß es. Auch er nicht.