REST-Schnittstellen

Nach und nach lösten REST-Schnittstellen die SOAP-Schnittstellen und weitere Protokolle ab. Dabei steht REST für Representational State Transfer. Bei REST handelt sich nicht um eine Bibliothek, welche zur Sprache von PHP mit dazukommt, sondern REST setzt direkt auf das HTTP-Protokoll auf und verschickt über dieses XML oder JSON oder auch beide Antworten. Dabei kommen unterschiedliche Zugriffspunkte auf dem Server zu tragen. Die Kommunikation ist, wie das HTTP-Protokoll auch, zustandslos, das bedeutet es besteht keine dauerhafte Verbindung zwischen einem Client und dem Server, so dass eine Authentifizierung jedesmal wiederholt werden muss.

Neben der Kommunikation zwischen Servern kann aufgrund der hohen Performance, das kapselndes XML wegfällt, REST auch innerhalb von vielschichtigen Applikationen genutzt werden. Man spricht in einem solchen Fall von einer REST-Architektur. Da zahlreiche Produkte existieren, die ein Loadbalancing von HTTP-Anfragen ermöglichen und REST auf HTTP aufbaut, können diese direkt genutzt werden, um einzelne Schichten dieser Architektur auf mehrere Serversysteme zu verteilen und so kostengünstig große Systeme aufbauen zu können.

REST nutzt vier HTTP-Kommandos. Von diesen sind uns schon die Kommandos GET von normalen HTTP-Anfragen – jede Standardanfrage eines Clients an einen Webserver ist eine GET-Anfrage – und die POST-Anfrage aus den Formularen bekannt. REST nutzt diese Kommandos wie folgt:

  • GET ohne Angabe einer ID: Liefert Listen von Objekten.
  • GET mit der Anhabe einer ID: Liefert das Objekt mit der ID.
  • HEAD mit oder ohne Angabe einer ID: Liefert nur die Kopfinformationen über die Liste oder das Objekt wie beispielsweise das letzte Änderungsdatum oder die Größe. Dies kann zu Cachingzwecken genutzt werden.
  • POST: Ein neues Objekt wird angelegt.
  • PUT mit der Angabe einer ID: Das Objekt mit der ID wird aktualisiert.
  • DELETE mit der Angabe einer ID: Das Objekt mit der ID wird entfernt.

REST nutzt die gleichen Möglichkeiten einen Client an einem Server zu authentifizieren, wie es auch HTTP tut. Gleiches gilt für die Festlegung der Kompression oder auch das Caching.

REST nutzt die Header-Variablen von HTTP. Diese sind…

  • ACCEPT, um dem Server mitzuteilen, was der Client als Antwort verarbeiten kann.
  • CONTENT-TYPE, um dem Client mitzuteilen, was tatsächlich geliefert wird.

Innerhalb von HTTP wird ein Status-Code einer Anfrage gesetzt, der anzeigt, welches Ergebnis die Anfrage hatte. Dieser Status-Code wird auch für REST genutzt:

  • 200 - OK: Anfrage ausgeführt
  • 201 - Created: Objekt angelegt
  • 204 - No Content: Kein Inhalt. Nützlich um ein \texttt{DELETE} zu bestätigen.
  • 400 - Bad Request: Nicht verarbeitbare Anfrage
  • 401 - Unauthorized: Authentifizierungsfehler. Meist fehlt die Anmeldung.
  • 403 - Forbidden: Authorisierungsfehler. Auf den Inhalt darf der Nutzer nicht zugreifen.
  • 500 - Internal Server Error: Serverseitiger Fehler

Das HATEOAS-Prinzip für Hypermedia as the Engine of Application State sagt aus, dass sämtliche URLs die von einem REST-Service abrufbar sind, durch Dokumente, die von diesem REST-Service ausgeliefert werden, erschließbar sind. Konkret bedeutet, dies, dass eine Liste an Objekten, die von einem REST-Service ausgeliefert wird, die Objekte bezeichnet, die dann einzeln über die IDs abgerufen werden können. Natürlich können in solchen Listen auch Unterlisten enthalten sein, die wiederum abgerufen werden können, um an Objekt-IDs zu kommen. Somit sind für eine Dokumentation des Services nur die Einsprungspunkte in den Service sowie das Format der Listen zu definieren. Von diesem Punkt an ist der Service selbsterklärend. Es gilt als ein Zeichen eines gut-durchdachten und nutzerfreundlich REST-Dienstes, wenn dieser dem HATEOAS-Prinzip folgt.

Im folgenden wird gezeigt, wie einfach ein Server einen REST-Dienst bereitstellen kann und wie auf diesen zugegriffen werden kann. Zunächst wird der Serverteil vorgestellt:

Dieses kleine PHP-Skript ist bereits ein kompletter REST-Dienst. Er ist eine vereinfachte Implementierung eines dieses, der Textdateien abspeichern kann, um sie hernach wieder auszuliefern. Um das HATEOAS-Prinzip zu erfüllen, wird eine Liste der Dateien ausgegeben, wenn man den Dienst mit der Methode GET ohne einen Parameter aufruft. In den letzten Jahren sind immer mehr Storage-Clouds bereit gestellt worden. Der Dienst, der hier vorgestellt ist, ist bereits eine einfache Schnittstelle zu einer Storage-Cloud.

In den ersten sechs Zeilen ist zu sehen, wie die Parameter aus dem Request extrahiert werden. Dabei wird die HTTP-Methode extrahiert. Dann wird — falls vorhanden — der Dateiname aus der Anfrage entnommen. Zuletzt werden die übergebenen Daten intern in einem String abgelegt.

Über das folgende Switch-Konstrukt wird nun die Anfrage bearbeitet. Dabei wird entweder die Datei gelesen und zurückgeliefert oder das Verzeichnis gelistet, die Datei gelöscht oder die Datei geschrieben.

Es sei darauf hingewiesen, dass Sie dieses Skript nicht produktiv nutzen sollten. Es finden noch keinerlei Sicherheitsprüfungen statt. Weiterhin existiert auch keine Fehlerbehandlung.

Sie können nun dieses Skript unter dem Namen server.php in Ihrer Entwicklungsumgebung ablegen. Alle Adressen, die mit server.php/ enden, werden nun von Ihrem REST-Dienst verarbeitet.

Der Client, der auf diese REST-Schnittstelle zugreifen kann, sieht wie folgt aus:

Leider sind die Möglichkeiten auf REST zuzugreifen in PHP etwas sperrig. Deshalb ist im Skript zunächst eine Hilfsfunktion executeRESTCall() definiert, die über die CURL-Schnittstelle von PHP den REST-Dienst anspricht. Diese kann nun, wie in der letzten Zeile des Clients gezeigt, genutzt werden, um REST-Aufrufe abzusetzen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert