Le principe de statelessness du web veut que chaque requête à un serveur web se fasse sans avoir à connaître d’état, ou sans connaissance de requêtes précédentes.
De facto, le web n’est pas conçu pour porter des processus qui induiraient une suite logique de tâches A, B puis C.
En principe, on doit toujours pouvoir faire des retours arrière avec son navigateur, or ce n’est pas toujours le cas, il y a des violations du principe d’absence d’état (statelessness) ou vous ne pouvez pas revenir en arrière (ou alors votre navigateur vous demandera de réenvoyer des données pour pouvoir retrouver le fil ).
Par essence, un serveur web ne sait pas ce que vous avez fait ni ce que vous allez faire au moment de répondre à la requête d’un client web.
Chaque échange entre un client HTTP et un serveur est un « one shot« , une histoire sans lendemain.
Une architecture conforme aux principes REST ne peut donc théoriquement pas proposer des services en mode Business Process Management.
Autres notes similaires :
- Un groupe de travail du W3C a produit un Working Draft afin d’avoir le vocabulaire HTTP en RDF. Quel intérêt ? Quand les mécanismes de négociation entre un client et un serveur Web deviennent critiques – et pour des questions de qualité et de conformité – il vaut mieux stocker les échanges entre le client [...]......
- O’Reilly signale la disponibilité de CoScripter qui sort du centre de recherche d’IBM à Almaden. Ce plugin pour Firefox permet de faire des scripts de requête sur le web. Ainsi, l’on peut faire un script d’une recherche d’appartement, d’une réservation d’avion, etc. Tout ce qui se fait par formulaire peut donc être automatisé grace au [...]......
- RESTful Web Services est peut-être l’ouvrage informatique de l’année. Je vais tenter d’expliquer le plus simplement possible l’enjeu de cet ouvrage. Internet, c’est le protocole TCP/IP. Protocole sur lequel s’appuient d’autres protocoles comme HTTP, SMTP, FTP, SNMP, TELNET, DNS, SSH, etc. Le langage courant a tendance à confondre le Web et Internet. Or le Web, [...]......
{ 3 comments… read them below or add one }
Je ne comprends pas bien ton propos…
Dans des expériences passées, il me semble avoir travaillé dans un environnement où la session utilisateur comportait énormément d’informations et en particulier des informations permettant de vérifier si l’enchaînement des étapes d’un processus était respecté.
Les applications de workflow documentaires sont toutes basées là-dessus, non ?
Peut-être ai-je mal compris le sens de ton message…
Le protocole http est stateless.
C’est pourquoi depuis l’asp de microsoft – puis php, etc etc. les serveurs proposent un service qui permet de mimer l’état d’une session. Mais c’est uen reconstitution a posteriori, qui se base sur ce protocole mais l’exploite à fond pour pallier ce manque.
Pour cela le serveuir utilise un cookie ou il passe un identifiant dans l’url – qui permet de savoir quel est l’utilisateur qui fait la requête. Puis pour chaque utilisateur, pour chaque requête, il reconstitue un contexte de données à partir de cet identifiant.
De même le protocole ne gère pas la « conversation » (le flow).
l’aspect stateless du web est à la fois sa force et sa faiblesse. Sa faiblesse parce que ça manque vraiment – et on est obligé de jongler pour être sûr de son coup.
Sa force parce que ça allège considérablement le protocole d’échanges, ça rend le web très solide.
Non seulement je n’ai plus besoin de répondre mais en plus j’apprends des choses.
Merci Gabriel.
{ 1 trackback }