Formulaires avec les méthodes PUT et DELETE en HTML 4.01 (partie 2/2)

Exemple d’utilisation

Dans ce document, on va voir comment utiliser ces deux méthodes.

Pour commencer, seules les méthodes GET et POST sont supportées et traitées de la même manière par tous les navigateurs. Les spécifications HTML jusqu'à 4.01 ne définissent aucun support PUT/DELETE pour les formulaires, et seulement GET et POST sont supportés. Du fait que ces deux méthodes PUT/DELETE sont de plus en plus utilisées, HTML 5 définit une spécification pour PUT/DELETE.

En dehors d’HTML 5, un navigateur qui respecte strictement la spécification w3c [3] de HTML ne supporte pas PUT et DELETE, et c'est la valeur GET qui est envoyée par défaut si la méthode n'est pas reconnue.

L'exemple suivant illustre bien ce problème.


<body>
<h1>Hello World!</h1>
<form action="restTest" method="PUT">
<input type="text" name="NOMBRE" value="" />
<input type="submit" value="PUT" />
</form>
</body>

Figure 1. Formulaire avec méthode PUT en HTML 4.0

L'exemple illustre un simple formulaire avec un champ texte et un bouton. L'analyse des requêtes échangées lors du clic sur le bouton prouve que la méthode est GET.

Figure 2. Analyse des requêtes HTTP échangées

Étudions maintenant l'exemple suivant. On associe au bouton, lorsqu'on clique dessus, une action définie en JavaScript.


function putrequest()
{
xhr=window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
xhr.onreadystatechange=function(){//TODO...};
xhr.open("PUT","http://localhost:8084/rest/restTest");
xhr.send(null);
}

Figure 3. Méthode PUT avec l'objet XMLHTTPRequest

Nous définissons la requête à travers l'objet XMLHTTPRequest et nous spécifions la méthode PUT. Le but ici est de vérifier bien que le serveur d'application Apache Tomcat gère et accepte bien les requêtes PUT et DELETE.

Figure 4. Analyse des requêtes HTTP échangées (PUT avec XMLHTTPRequest)

L'objet XMLHTTPRequest fait appel à la servlet restTest, où est redéfinie la méthode doPost. HTTP Analyser (HTTPFox pour Firefox) montre bien que la méthode PUT est supportée par l'objet XMLHTTPRequest et le serveur Tomcat a bien exécuté la méthode doPost.

La servlet RestTest appelée détecte la méthode PUT et fait appel à la méthode doPut redéfinie dans la servlet. L’implémentation par défaut de doDelete et doPut ne fait que rendre des messages.

Or, un tel appel ne reflète pas vraiment une méthode PUT ou DELETE et peut être remplacé par un appel POST ou GET. En effet ces deux méthodes servent à insérer, mettre à jour ou supprimer des ressources.

Modifions le code précédent de la manière suivante:


<script type="javascript">

function putrequest()
{
xhr=window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
xhr.onreadystatechange=function(){//TODO...};
xhr.open("PUT","http://localhost:8084/rest/welcome.html");
xhr.send("<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>JSP Page</title></head><body><h1>Hello World!</h1></body></html>");
}
</script>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
</head>
<body>
<h1>Hello World!</h1>
<button onclick="putrequest">PUT</button>
</body>
</html>

Figure 5. Ajout d'une nouvelle ressource

Dans cet exemple, on spécifie l’URI de la ressource demandée (welcome.html à ajouter). Comme on n’a pas défini aucune correspondance entre l’url demandée et une servlet, tomcat fait appel à la servlet par défaut (DefaultServlet [4]) pour servir les ressources. Cette servlet redéfinit les méthodes doPut et doDelete pour effectuer le traitement nécessaire. Le corps de la nouvelle page à ajouter est envoyé dans par la méthode send. La spécification w3c pour l’objet XMLHTTPRequest définit le type des données envoyées par la méthode send comme étant document ou string.

Figure 6. Réponse à une méthode PUT

Pour des raisons de sécurité, Tomcat ne permet pas par défaut la manipulation des ressources. Ainsi, le serveur génère une erreur 403 liée aux droits de modification. Pour activer ce mode, il faut mettre le paramètre readonly de la servlet par défaut à false (modification du fichier web.xml dans le dossier conf).

Figure 7. Configuration du fichier web.xml

Il sera mieux de définir notre propre servlet qui s’inspire de DefaultServlet et bien configurer le fichier web.xml propre à notre application pour définir la correspondance entre cette servlet et le pattern des URI. Il faut aussi penser à créer des contraintes de sécurité pour les ressources (authentification et rôle dans web.xml).

Figure 8. Analyse des requêtes HTTP échangées (PUT avec XMLHTTPRequest)

La page est bel est bien crée dans cet exemple et on peut directement y accéder en tapant l’url y correspondant. Le code de retour est 201 si la ressource est créée, et 204 si elle est mise à jour.

Pour utiliser PUT et DELETE dans un formulaire en HTML 4, on peut définir une action JavaScript associée au bouton et qui récupère les différents champs et envoie la requête correspondante.

[3] HTML4.01 specification for the form element.

[4] Default Servlet Reference.

Formulaires avec les méthodes PUT et DELETE en HTML 4.01 (Partie 1/2)

Le protocole Hypertexte Transfer Protocol (HTTP) est un protocole de communication client/serveur inventé par Tim BERNES-LEE dans le but de supporter la notion de format de données introduite par le Multipurpose Internet Mail Extension (MIME) pour le World Wide Web.

Actuellement, il est en sa version 1.1 définie par la RFC 2616. Il décrit le format des messages échangés ainsi que les méthodes spécifiant le type de la requête et l'action à faire. On compte les huit méthodes suivantes dans la version actuelle de HTTP:

  • GET : cette méthode permet la récupération d'une ressource du serveur identifiée par son URI. C'est une opération sûre (safe) et sans effet de bord (idempotente).

  • POST : cette méthode permet d'envoyer des données au serveur et requêter une URI. La puissance de cette méthode réside au fait qu'on peut définir n'importe quel processus de traitement des données envoyées côté serveur. Ainsi cette méthode est non idempotente (paiement bancaire par exemple) et non sûre (injection SQL par exemple).

  • PUT : cette méthode permet d'ajouter et mettre à jour des ressources serveur. A la différence de POST, PUT permet de manipuler directement des ressources, alors que POST fait appel à des actions définies par l'URI et qui peuvent porter sur des ressources. PUT est non sûre (action directe sur les ressources serveur même sur les fichiers), mais elle est idempotente.

  • DELETE : elle permet de supprimer une ressource serveur. Comme PUT, cette méthode est idempotente mais non sûre.

  • HEAD : utilisée pour demander les informations sur une ressource mais pas la ressource elle même.

  • OPTIONS : permet de savoir les OPTIONS de communication d'une ressource ou du serveur.

  • CONNECT : permet d'utiliser un proxy comme tunnel de communication.

  • TRACE : permet de demander au serveur d'envoyer une TRACE de ce qu'il a reçu.

Les méthodes les plus utilisées sont GET et POST.

REST

Aujourd'hui avec l'explosion des services web de type REST (Representational State Transfer), les méthodes PUT et DELETE attirent plus l'attention. REST est un type d'architecture et de design orienté ressources, défini par Roy THOMAS FIELDING, basé sur HTTP, XHTML et les URIs [1] et permettant de définir des services web en respectant la sémantique initiale d'HTTP.

L'idée de base de REST est de ne manipuler que des ressources. Chaque service est défini par une action d'ajout, mise à jour ou suppression d'une ressource représentée par son URI. La définition d'une URI est libre, mais en général, on utilise la hiérarchisation par niveau de priorité. Voici un exemple d'une URI

HTTP://www.ideotechnologies.com/Employes/RetD/GhassenOueslati

HTTP définit un ensemble d'en-têtes permettant de décrire la représentation de la Ressource. En REST, le nombre d'actions possibles est réduit, et en général on n'utilise que GET, POST, PUT et DELETE. L'avantage est qu'on n'a pas besoin d'une description WSDL comme en SOAP pour savoir les noms des méthodes.

À la différence de POST, les méthodes PUT et DELETE agissent directement sur les ressources d'un serveur définies par les URIs. En REST, POST n'envoie que des variables exploitables par le serveur. En d'autres termes, la ressource pour une requête POST, doit être une donnée soumise à un processus de traitement défini par le serveur.. Dans le cas de PUT ou DELETE, le serveur agit directement sur la ressource soit par création, mise à jour ou suppression. Toutefois, il est possible de définir l'insertion d'une ressource serveur avec POST, mais finalement ce n'est pas le but de cette méthode. POST permet de définir des actions diverses, alors que PUT, par défaut permet l'insertion ou la suppression d'une ressource serveur [2].

Notion qui fait référence à la définition de la sécurité du serveur. Une méthode est sûre si elle n’affecte pas les ressources serveur.

Une méthode est idempotente (sans effets secondaires ou de bord) si son appel successif plusieurs fois de suite n’entraîne pas un dysfonctionnement ou une anomalie soit sur le fonctionnement interne soit sur la cohérence métier.

[1] Restful Web Services. Leonard Richardson ET Sam Ruby.

[2] Why PUT and DELETE. Interview with Elliote RUSTY HAROLD.