Im Rahmen meines Studiums wurde ich neulich mit einem Thema konfrontiert, das mich seit dem ziemlich beschäftigt hat. Die Rede ist von REST. REST ist eine Abkürzung für Representational State Transfer.
Im Grunde hatte ich mich auch vorher schon damit auseinandergesetzt ohne es zu merken. Im Folgenden möchte ich das Theme REST kurz vorstellen und Anregungen geben, sich tiefer gehend mit dem Thema auseinanderzusetzen.Bei REST handelt es sich um ein Programmierparadigma, also um einen Stil, der unabhängig von der eingesetzten Programmiersprache oder anderer technischer Rahmenbedingungen umgesetzt werden kann.
REST ist keine normierte Vorschriftensammlung, sondern viel eher eine grundsätzliche Idee, wie man Programmschnittstellen (APIs) analog zum verbreiteten HTTP-Standard adressierbar machen kann.
Zugegeben, das klingt zunächst recht kompliziert, ist aber im Grunde ganz einfach. Ein Beispiel soll zeigen, was damit gemeint ist: Stellen Sie sich eine Server-basierte Notizverwaltung vor. Das ganze könnte z.B. in PHP oder JAVA umgesetzt sein. Client-seitig sollen z.B. mittels JavaScript die Eingaben des Benutzers entgegengenommen werden und mittels HTTP-Request eine Anfrage an den Server geschickt werden.
Die Grundfunktionalität soll folgendes abdecken:
- Alle Notizen zu einem Objekt empfangen
- Eine neue Notiz zu einem Objekt abgeben
- Eine Notiz zu löschen
- Das Passwort des Nutzers ändern
Was genau ein “Objekt” in diesem Fall ist, spielt gar keine so große Rolle. Es könnte sich dabei beispielsweise um die Folien einer Präsentation handeln.
Wir haben nun also eine grobe Beschreibung der Funktionen und wissen, dass es sich um eine Server-Client-Anwendung handeln soll. Doch was hat nun REST damit zu tun? Ganz einfach: REST bestimmt, dass sich der Client einen request an eine bestimmte Resource im Web abgibt, die per URI genau definiert wird und vom Server verwaltet wird. Für unsere drei Funktionen wären die folgenden URIs sinnvoll:
- http://extremeprogrammer.de/{user}/{object}/
- http://extremeprogrammer.de/{user}/{object}/
- http://extremeprogrammer.de/{user}/{object}/{note}
- http://extremeprogrammer.de/{user}/
Die URI-Abschnitte in den geschweiften Klammern werden durch den konkreten Nutzer bzw. das konkrete Objekt bestimmt.
Es fällt dabei auf, dass die ersten beiden URIs gleich sind. Aber wie kann denn nun der Server unterscheiden, ob er Notizen zu einem Objekt zurück geben soll oder ob er eine neue Notiz anlegen soll? Diese Unterscheidung findet über die Art des HTTP-Requests statt. Sicher haben Sie schon etwas von GET und POST gehört. Diese sind Teil der HTTP-Spezifikation. Vieleicht haben Sie sich auch schon einmal gefragt, wo genau der Unterschied liegt. Nun, das W3C hat festgelegt, dass GET Resourcen abfragen. POST kommt immer dann zum Einsatz, wenn eine neue Resource hinzugefügt wird.
Neben POST und GET gibt es noch etliche weitere Anfragetypen – hier sind noche inmal die wichtigsten vier zusammengefasst:
- GET: Wird verwendet, um Informationen abzufragen
- POST: … um eine neue Resource zu erstellen
- PUT: … um eine bestehende Resource abzuändern (update)
- DELETE: … um eine Resource zu löschen
Mit diesen vier Anfragetypen können wir die Grundfunktionalität unseres Beispielprogramms umsetzen. Zwei Dinge sind an dieser Stelle noch wichtig zu erwähnen: Eine GET-Anfrage erhält als Antwort Informationen. REST selbst legt nicht fest, in welchem Format dies zu geschehen hat. In der Praxis haben sich JSON und XML als Quasi-Standards etabliert. Definiert wird der Rückgabetyp über den HTTP-Header mit dem Namen “Content-Type”.
Übrigens kann es auch sinnvoll sein, POST, PUT oder sogar DELETE-Requests mit einem Rückgabewert zu versehen. Für eine fehlgeschlagene Operation werden die Standard HTTP-Status-Codes verwendet. Hier ein paar Beispiele:
- 200: OK
- 400: Der request hat eine fehlerhafte Syntax
- 401: Der request muss mit Anmeldeinformationen versehen werden
- 403: Der Zugriff auf die Ressource wurde verweigert
- 404: Resource nicht vorhanden
hier gibt es die komplette Liste aller Status-Codes mit Beschreibung: w3c.org
Das zweite wichtige Feature ist das übermitteln von Werten an den Server. Wie sinnlos wäre ein POST-Request, wenn ihm keine Information über das zu erstellende Objekt beigefügt wären? Dafür bietet das HTTP-Protokoll eine Menge von Schlüssel-Wert-Paaren, wobei sich hierbei anbietet ein Schlüssel-Wert-Paar mit einem JSON- oder XML-String zu befüllen.
Das war auch schon das Grundprinzip, das hinter REST steckt. In ein paar kurzen Sätzen lässt sich REST so zusammenfassen:
- Adressierbarkeit: Resourcen werden über eindeutige Adressen (URIs) angesprochen. Diese ändern sich nicht!
- Datenrepräsentation: Die Daten können unterschiedlich formatiert werden. XML und JSON sind Quasi-Standards
- Zustandslosigkeit: Bei einer REST-konformen Architektur müssen severseitig keine Session-Informationen gespeichert werden: Jeder Request muss für sich genommen ausführbar sein. Auf das Thema Authentifizierung soll an dieser Stelle nicht weiter eingegangen werden. Hierfür gibt es verschiedene Standards wie z.B. BasicAuth.
- Wohl definierte Operationen: Beispielsweise werden mit GET Daten abgefragt und nicht verändert! Halten Sie sich an die HTTP-Spezifikationen!
- Hypermedia: Das REST eng mit dem surfbaren Web verknüpft ist, ist es vorgesehen, dass Rückgaben URIs zu weiteren Informationen enthalten können.
ich hoffe, ich konnte Ihnen einen kleinen Einblick in die Architekturgrundsätze von REST geben. Bei Fragen und Anregungen stehe ich Ihnen – wie immer – gerne zur Verfügung. Hier gibt es nochmal eine kleine Auswahl an Büchern, die sich teilweise recht ausführlich mit dem Thema REST auseinandersetzen.
