Teil 4: Webservices mit PHP selbst gemacht
- Webservices mit PHP selbst gemacht
- Teil 2: Webservices mit PHP selbst gemacht
- Teil 3: Webservices mit PHP selbst gemacht
- Teil 4: Webservices mit PHP selbst gemacht
- Teil 5: Webservices mit PHP selbst gemacht
Das Zend-Framework bietet für einige dieser frei verfügbaren Services eine fertige API an, sodass man hierfür nicht mehr mit WSDL-Dateien und Webservice-Clients arbeiten muss. Alternative: REST SOAP-Webservices haben sich über lange Zeit den Status des Defacto-Standards für Webservices erar...
Das Zend-Framework bietet für einige dieser frei verfügbaren Services eine fertige API an, sodass man hierfür nicht mehr mit WSDL-Dateien und Webservice-Clients arbeiten muss.
Alternative: REST
SOAP-Webservices haben sich über lange Zeit den Status des Defacto-Standards für Webservices erarbeitet. Ihnen eilt aber der Ruf voraus, umständlich und mit viel Overhead behaftet zu sein. Wie wir bereits gesehen haben, ist dieser Ruf nicht ganz unbegründet.
Aus dem Jahr 2000 stammt ein alternativer Architekturentwurf, der im Rahmen einer Dissertationsarbeit von Roy Fielding entstand. Der REST genannte Entwurf steht für Representational State Transfer. Bei REST sind alle Services sogenannte Ressourcen, die alle eine eindeutige URI besitzen.
Komplett per HTTP
Im Gegensatz zu SOAP konzentriert sich REST komplett auf das HTTP-Protokoll als Kommunikationsmittel. Dank des World Wide Web ist HTTP heute ein weit verbreiteter und absolut stabiler Standard. Webbrowser nutzen das HTTP-Protokoll um Daten vom Webserver abzufragen und dorthin zu übertragen. Browser nutzen dazu die zwei Anfragearten GET und POST des HTTP-Protokolls. Anfragen über GET sind prinzipiell dazu gedacht, Daten vom Server abzurufen.
Die Informationen, die für den Abruf der Daten benötigt werden, können direkt in der URL spezifiziert werden (zum Beispiel https://domain/user/get/id/17). Per POST werden Daten an den Server übertragen. POST ist daher die Methode der Wahl bei der Übertragung von Formulardaten.
Damit sind die Möglichkeiten eines Browsers ausgeschöpft, aber die des HTTP-Protokolles noch nicht. HTTP definiert noch weitere Methoden.
Put, Delete, Get, Post
Im Moment sind für uns lediglich PUT und DELETE interessant. Auf diesen vier Methoden basiert REST, um verschiedene Operationen auf eine Ressource auszuführen. Bleiben wir bei dem Beispiel eines Benutzers für eine Ressource, dann haben die vier Operationen folgende Bedeutung:
• GET: Die GET-Methode sorgt wie bei Webseiten dafür, dass Daten einer Ressource gelesen werden. Der Aufruf der URL https://localhost/User/17 würde so beispielsweise den Benutzer mit der ID 17 lesen und an den aufrufenden Client zurückliefern. • POST: Die POST-Methode dient zum Schreiben neuer Einträge. Ganz ähnlich wie bei POST-Aufrufen aus einer Webseite (zum Beispiel Formulare) werden die Daten nicht in der URL, sondern im Body der HTTP-Nachricht übertragen. • DELETE: Hier ist der Name der Operation eigentlich selbsterklärend. Der Aufruf einer URL per DELETE-Methode führt dazu, dass ein Objekt gelöscht wird. Der Aufruf der URL https://localhost/User/17 würde beispielsweise dazu führen, dass der Benutzer mit der ID 17 gelöscht wird. • PUT: Die PUT-Methode entspricht einem Update einer Ressource. Auch hier werden die Daten im Body der HTTP-Nachricht an den Server übertragen.
Wie im folgenden Beispiel zu sehen ist, spielt die Art des Webservices bei der Verwendung des Zend-Frameworks kaum eine Rolle. Die Service-Klasse an sich bleibt unverändert. Der einzige Unterschied liegt in der Verwendung der Zend_Rest_Server-Klasse anstelle der Zend_Soap_Server.
Implementierung des Servers
<?php
require_once 'Zend/Rest/Server.php';
/**
* Say Hello
*
* @param string $who
* @return SimpleXMLElement
*/
function sayHello($who) {
return return 'Hallo '.$who;
}
$server = new Zend_Rest_Server();
$server->addFunction('sayHello);
$server->handle();
?>Damit haben wir unseren ersten REST-Webservice-Server fertiggestellt.
