Apache La référence Ben Laurie Et Peter Laurie

Prev Next

Les sites web en tant qu’applications

Bien que de nombreux sites soient de simples dépôts de documents et qu’ils fournissent à leurs visiteurs un ensemble de fichiers entre lesquels ils peuvent naviguer grâce à des liens hypertextes, les sites web sont capables d’interactions bien plus sophistiquées. Les sites peuvent collecter des informations fournies par les utilisateurs via des formulaires, adapter leur apparence et leur contenu en fonction d’intérêts particuliers ou permettre aux utilisateurs d’interagir avec un grand nombre de sources d’informations. Les sites peuvent également héberger des services destinés, non pas à des navigateurs, mais à d’autres ordinateurs : ces « services web » prennent une place croissante dans l’informatique actuelle.

Apache fournit une base solide pour les applications : le serveur web, qui est son cœur même, gère les transactions HTTP et sa grande variété de modules et d’interfaces permet de connecter ces transactions à des programmes. Les développeurs peuvent programmer des traitements pouvant gérer des flux d’informations bien plus complexes qu’une simple lecture de pages, ils peuvent utiliser l’environnement de développement de leur choix, ainsi que les services d’Apache concernant HTTP, la sécurité et les autres aspects spécifiques au Web de leur application. Tout est possible, de la simple inclusion d’informations à l’intégration sophistiquée d’environnements et d’applications hétérogènes.

Plus de détails sur HTTP

Lorsque nous avons mis un site en ligne, nous ne nous sommes intéressé qu’à une seule méthode du protocole HTTP : GET. La gestion de base d’Apache pour cette méthode convient tout à fait aux sites qui n’ont besoin que de publier des informations contenues dans des fichiers, mais HTTP (et Apache) permet beaucoup plus de choses. Les développeurs qui souhaitent créer des sites interactifs devront écrire des programmes pour fournir les traitements de base. Cependant, de nombreuses tâches sont simples à mettre en place et Apache est très capable de gérer des applications bien plus complexes, comme la connexion à des bases de données ou à d’autres sources d’informations.

Toute requête HTTP doit préciser la méthode qu’elle utilise afin d’indiquer au serveur comment traiter les données qu’il reçoit. Si vous souhaitez connaître tous les détails, consultez la spécification de HTTP/1.1 (http://www.w3.org/Protocols/rfc2616/rfc2616.html). Brièvement, ces méthodes sont les suivantes :

GET

Renvoie les données demandées. Pour économiser le trafic réseau, un « GET conditionnel » ne renverra des données que si la condition est vérifiée. On peut ainsi transmettre une page qui est modifiée fréquemment : si le client la redemande et qu’elle n’a pas été modifiée depuis la dernière fois, le GET conditionnel produira une réponse indiquant au client qu’il doit la récupérer dans son cache local (GET peut également contenir des informations de chemin supplémentaires, ainsi qu’une chaîne de requête avec les informations requises pour une application).

HEAD

Renvoie les en-têtes qui auraient également été inclus dans un GET, mais sans les données. Cela permet de tester la fraîcheur du cache du client sans dépenser de la bande passante pour récupérer le document complet.

POST

Demande au serveur de recevoir les données et de les traiter en utilisant la ressource identifiée par l’URL (souvent, il s’agira du de la valeur du champ ACTION d’un formulaire HTML mais, en principe au moins, elle pourrait être produite d’une autre façon). Lorsque vous achetez un livre sur le Web, par exemple, vous remplissez un formulaire en indiquant le titre de ce livre, votre numéro de carte de crédit, etc. puis, votre navigateur POST ces données au serveur.

PUT

Indique au serveur qu’il doit stocker les données.

DELETE

Indique au serveur qu’il doit supprimer les données.

TRACE

Indique au serveur qu’il doit renvoyer une trace des actions qu’il entreprend.

CONNECT

Demande à un mandataire de se connecter à un autre hôte et de simplement relayer le contenu, plutôt que de tenter de l’analyser ou de le mettre en cache. Cette méthode est souvent utilisée pour établir des connexions SSL à travers un mandataire.

Les serveurs ne doivent pas nécessairement implémenter toutes ces méthodes : consultez le RFC 2068 pour plus de détails. Les méthodes les plus fréquemment utilisées sont GET et POST, qui gèrent la grande majorité des interactions avec les utilisateurs.

Création d’un formulaire

Les formulaires sont le type d’interactions le plus fréquent entre les utilisateurs et les applications web car ils fournissent bien plus de possibilités que de simples liens hypertextes. HTML dispose d’un ensemble de composants permettant de récolter les informations auprès des utilisateurs, informations que HTTP transmet ensuite au serveur en utilisant la méthode de votre choix. Du côté du serveur, votre application traite les informations provenant du formulaire et, généralement, répond à l’utilisateur d’une façon appropriée.

La création d’un formulaire consiste simplement à éditer notre brochure originale pour la transformer en formulaire. Nous souhaitons simplement ajouter quatre champs pour saisir le nombre d’exemplaires que veut le client pour chaque carte et, en bas, un champ pour le numéro de sa carte de crédit.

Le catalogue est désormais un formulaire, où les nouvelles lignes sont indiquées par :

Il ressemble à ceci :

<html>

<body>

<h1> Bienvenue chez Butterthlies Inc</h1>

<h2>Catalogue Eté</h2>

<p> Toutes nos cartes sont disponibles par paquets de 20, à 2 euros le paquet.

Une remise de 10% est consentie pour toute commande de plus de 100 cartes.

</p>

<hr>

<p>

Style 2315

Allongé sur un banc

<p>Combien de paquets de 20 voulez-vous ? <INPUT NAME="2315_order" >

<hr>

<p>

Style 2316

Dans le poulailler

<p>Combien de paquets de 20 voulez-vous ? <INPUT NAME="2316_order" >

<HR>

<p>

Style 2317

En haut de l’arbre

<p>Combien de paquets de 20 voulez-vous ? <INPUT NAME="2317_order">

<hr>

<p>

Style 2318

<p align="center"> Tout sale dans le bain

<p>Combien de paquets de 20 voulez-vous ? <INPUT NAME="2318_order">

<hr>

<p> Quel type de carte de crédit utilisez-vous ?

<ol>

<li>Carte Bleue <INPUT NAME="card_type" TYPE="checkbox" VALUE="Bleue">

<li>Carte Visa <INPUT NAME="card_type" TYPE="checkbox" VALUE="Visa">

<li>MasterCard <INPUT NAME="card_type" TYPE="checkbox" VALUE="MasterCard">

</ol>

<p>Numéro de carte : <INPUT NAME="card_num" SIZE=20>

<hr>

Nos cartes postales sont conçues par Harriet@alart.demon.co.uk

<hr>

<br>

Butterthlies Inc, Hopeful City, Nevada, 99999

</br>

</FORM>

</body>

</html>

Ce contenu est assez évident à comprendre, sauf peut-être la ligne :

qui, sous Windows, pourrait être :

Le marqueur <FORM> introduit le formulaire et </FORM> le termine. Son attribut METHOD indique à Apache comment renvoyer les données au script CGI que nous allons écrire : ici, nous utilisons POST.

Dans le cas d’Unix, l’attribut ACTION indique à Apache qu’il doit utiliser l’URL cgi-bin/mycgi.cgi (que le serveur peut traduire en interne par /usr/www/cgi-bin/mycgi.cgi, selon sa configuration) pour traiter tout cela.

Il serait bon que nous écrivions du HTML parfait, ce qui n’est pas le cas. Bien que la plupart des navigateurs admettent un peu de laisser-aller dans la syntaxe, ils n’autorisent pas tous cette même négligence aux mêmes endroits. Si vous écrivez du HTML qui ne respecte pas le standard, vos pages peuvent, parfois, se comporter bizarrement. Pour vous assurer que ce ne sera pas le cas, faites-les vérifier par un « validateur » -- http://validator.w3.org, par exemple.

Pour plus d’informations sur les nombreuses fonctionnalités fournies par HTML pour l’écriture des formulaires, consultez HTML et XHTML, la référence, de Chuck Musciano et Bill Kennedy.

Autres approches pour construire des applications

Bien que les formulaires HTML soient sans doute la forme la plus utilisée pour les applications web, il y a bien d’autres cas où les utilisateurs interagissent avec des applications sans nécessairement remplir un formulaire. Les sites importants utilisent souvent des systèmes de gestion de contenu pour stocker dans des bases de données les informations qu’ils présentent ; ils produisent du contenu de façon dynamique, même si les utilisateurs ont l’impression qu’il s’agit d’un site ordinaire proposant des fichiers statiques. Même des sites moins importants peuvent utiliser des outils comme Cocoon (que nous présenterons au chapitre 19) pour gérer et produire les informations qu’ils proposeront à leurs utilisateurs.

De nombreux sites adaptent leur contenu en fonction de leurs utilisateurs, en utilisant les informations collectées lors de leurs précédentes visites ou de celles qu’ils ont fourni volontairement. Ces sites utilisent généralement des « cookies », un mécanisme permettant à un site de stocker un minimum d’informations sur l’ordinateur de l’utilisateur, que le navigateur enverra à chaque fois que cet utilisateur visite le site. Ces cookies peuvent durer le temps d’une seule session, et donc expirer lorsque l’utilisateur quitte le navigateur, ou persister plus longtemps pour expirer à une date précise. Ce mécanisme lève un certain nombre de problème liés à la protection de la vie privée mais il est couramment utilisé par les applications qui interagissent avec les utilisateurs pendant un temps supérieur à celui d’une simple transaction. Avec les cookies, un site web peut, en fait, produire des pages propres à chaque utilisateur et s’adapter ainsi entièrement à son visiteur.

La construction d’applications web complexe dépasse le cadre de cet ouvrage. Pour plus d’informations sur la conception des applications web en général, consultez Information Architecture for the World Wide Web, de Louis Rosenfeld et Peter Morville. Pour en savoir plus sur la conception d’applications dans des environnements spécifiques, consultez les livres référencés dans les chapitres spécifiques à ces environnements.

Prev Next