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.

Un commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.