|
| |
| TUTORIEL PHP |
 |
|
|
| Créer des services Web avec SOAP et PHP |
| Dans cet article, nous allons écrire notre propre service Web avec les outils de base de PHP, et en faire un autre à l'aide de NuSOAP.
(13/05/2004) |
|
|
(fourni
par  )
Conception de l'application
En se basant sur la liste d'instructions ci-dessus, nous allons
écrire notre application et la décomposer en deux fichiers :
- insert.php (Listing
1), qui se charge de réaliser les commandes de type INSERT.
Nous allons écrire ce fichier sans utiliser de bibliothèque
NuSOAP, pour comprendre comment SOAP fonctionne.
- select.php (Listing
2), qui se charge des sélections. Dans ce cas, nous allons
tirer parti de NuSOAP, et voir combien cette bibliothèque est
utile.
N'oubliez pas que scinder un service Web en plusieurs fichiers
est une erreur, surtout si les buts des fichiers sont similaires.
Cependant, dans un but pédagogique, nous allons faire deux scripts
distincts, afin de bien illustrer la différence entre l'utilisation
ou non de NuSOAP.
La table sur laquelle les deux scripts vont travailler s'appelle
'people'; sur mon serveur, elle est installée dans la base 'test'
et a la structure suivante :
CREATE TABLE people (
id int (10) unsigned NOT NULL auto_increment,
name varchar (30) NOT NULL,
age tinyint (3) unsigned NOT NULL,
city varchar (30) NOT NULL,
PRIMARY KEY (id)
) TYPE = MyISAM;
Les deux
scripts ont besoin des informations de connexion, enregistrées
dans les paramètres USER et PWD. Insert.php va aussi avoir besoin
des paramètres NAME, AGE et CITY, et après insertion dans la
table people, il va retourner deux valeurs : STATUS, qui sera
"OK" si tout s'est bien passé, et TIME, qui contiendra l'heure
locale d'insertion. select.php, pour sa part, va demander en
plus des informations d'identification, un identifiant ID, qui
sera utilisé pour effectuer la requête. Ce script va retourner
le nom NAME, l'age AGE et la ville CITY : ces informations sont
lues dans les lignes de la table people. On y adjoint l'heure
courante TIME.
Coder SOAP sans NuSOAP
Dans le Listing 1, vous pouvez voir une classe appelée SOAP,
que nous allons utiliser pour analyser les données XML, et pour
envoyer les messages d'erreur et les réponses. Les méthodes
de cette classe sont SOAPparse(),
ParseStart(), ParseEnd()
et doParsing(). Elles sont explicites,
et sont utilisées pour s'interfacer avec l'extension XML de
PHP. La méthode principale est SOAPparse(),
qui requiert un document XML dans le paramètre $xml,
sous forme de chaîne. La fonction commence par créer un analyseur
XML appelé $parser et le stocke
dans l'objet courant en utilisant la fonction xml_set_object();
c'est obligatoire si vous voulez utiliser un analyseur XML à
l'intérieur d'un objet.
A la ligne suivante, nous utilisons xml_set_element_handler()
pour définir les fonctions que nous voulons utiliser lors de
la rencontre d'une balise ouvrante ou d'une balise fermante,
durant l'analyse du document XML. Ces deux fonctions, ParseStart()
et ParseEnd() peuvent prendre
n'importe quel nom, mais le prototype doit suivre le schéma
suivant :
function ParseStart($parser, $name,
$attribs)
function ParseEnd($parser, $name)
Si ce schéma n'est pas suivi, le script ne pourra pas fonctionner.
Dans notre listing, ParseStart()
et ParseEnd() sont déclarées
comme des méthodes de la classe SOAP.
La ligne suivante est très importante : nous utilisons la fonction
xml_set_character_data_handler()
pour relier la méthode qui va faire le plus gros du travail
avec notre analyseur XML. C'est ce que la fonction doParsing()
fait pour nous : nous stockons les données brutes de $data,
c'est-à-dire les données contenues entre les balises XML, dans
un tableau associatif, en utilisant le nom de la balise courante
comme index. $currTag a été
déclarée comme une variable globale, dans toutes les méthodes.
Cela signifie que nous allons aboutir au tableau $this->req,
qui stocke chaque valeur de balises XML.
La méthode fault() intervient
lorsqu'une erreur survient. Elle renvoie deux entêtes à l'application
appelante : le premier entête est un code d'erreur, "500 Internal
Server Error", et le second est une spécification de type 'Content-type',
qui indique au client que les données sont au format XML. Nous
affichons un message SOAP, qui est ici écrit en dur dans le
script, grâce à la syntaxe HereDoc. Ce message explique le type
d'erreur, contenu dans le paramètre $type,
qui peut être 'Client' pour indiquer une erreur de requête malformée,
ou bien 'Server', pour indiquer que l'erreur est du coté du
serveur. On trouve aussi l'exécutant principal dans la variable
$actor, pour indiquer qui a
rencontré l'erreur : ce peut être "MySQL" ou "Bad Request".
Enfin, on trouve une explication détaillée de l'erreur, dans
la variable $msg. Après avoir
imprimé le message, le programme s'arrête.
Le cur sur service Web
Une fois que nous avons écrit la classe principale, nous pouvons
attaquer l'application elle-même : tout d'abord, une instance
de la classe SOAP est créé, et stocké dans la variable $s.
Puis, nous vérifions que :
- la requête a été soumise via la méthode POST. Si ce n'est
pas le cas, nous considérons la requête comme malformée, et
nous affichons une erreur.
- le nom de l'utilisateur et le mot de passe, qui sont obtenus
une fois que l'analyse est terminée, sont stockés dans les membres
$s->req["USER"] et $s->req["PWD"],
et sont présents et valides.
- les autres paramètres ne sont pas vides.
Lorsqu'une des vérifications ci-dessus échoue, un message d'erreur
est affiché, et l'application s'arrête. Les erreurs qui peuvent
survenir à ce moment sont de type "Client", et elles indiquent
que la commande a été mal formée.
Si tout va bien, le programme continue et passe à la prochaine
étape. A ce moment, nous exécutons la requête elle-même. Tout
d'abord, nous la construisons, et nous stockons le code SQL
dans la variable $query. Nous
nous connectons à la base MySQL, sélectionnons la base test
et nous y exécutons la requête. Après chaque opération, nous
vérifions si MySQL a rapporté une erreur, et si c'est le cas,
nous émettons une erreur de type "Server".
Si aucune erreur ne survient, nous pouvons refermer la connexion,
et préparer la réponse SOAP. L'application indique que l'exécution
s'est bien déroulée, en envoyant deux entêtes : le premier indique
au client que l'opération a réussi : c'est le statut "200 OK".
C'est le contraire du code d'erreur. Le second entête contient
une spécification de type de contenu, qui sera XML : 'text/xml'.
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Finalement, nous imprimons le message SOAP, dont la structure
est très similaire au message d'erreur SOAP, hormis le fait
qu'il annonce un succès, et non pas une erreur. Cette fois-ci,
le corps contient le nom de la méthode qui a été exécutée, et
que nous avons appelé 'response'. Dedans, nous stockons le statut
STATUS, qui contient "OK" et l'heure TIME, qui contient la date
courante au format timestamp, obtenue dans la variable $time.
|
|
|
|
