-
La théorie
Le protocole HTTP permet à un client de lire, créer, modifier et supprimer des ressources
Pour éditer une ressource, le programme client doit envoyer une requête PUT à l'URL de la ressource cible, et placer les données dans le corps de la requête.
L'en-tête "Content-Type" permet au client d'indiquer le type des données (qui peut faire l'objet d'une négociation).
L'interprétation des données est à la charge du serveur.
-
Le problème
Si on utilise comme client un navigateur web classique (IE, Firefox, Lynx, ...), on est restreint aux méthodes GET et POST. Ce problème est bien connu des adepte de l'architecture REST.
Mais avant de pouvoir envoyer des données au serveur, le navigateur doit d'abord afficher un formulaire à l'utilisateur. Ce formulaire peut être vu comme une représentation de la ressource à modifier, au même titre que du HTML simple.
Aujourd'hui, le formulaire et la représentation HTML d'une ressource doivent «habiter» à des URLs différentes. Il me semble que c'est une limitation des navigateurs actuels.
-
Pourquoi ?
Une URL est l'adresse d'une ressource, et non celle de la représentation (entity) d'une ressource. Il paraît donc illogique d'avoir deux URLs pour la même ressource.
De plus, le protocole HTTP permet déjà la négociation de la représentation d'une ressource, au moyen de divers en-têtes (en particulier Accept, une liste de types MIME).
-
Comment ?
Si les navigateurs pouvaient savoir quand l'utilisateur souhaite modifier une ressource, ils pourraient demander au serveur une représentation comprenant un formulaire HTML, à la même URL que la ressource.
Il manque donc deux éléments :
- un type MIME indiquant du code HTML avec un formulaire, et
- un élément d'interface permettant à l'utilisateur de demander l'édition d'une ressource.
Le type MIME pourrait être par exemple : text/html+form.
L'élément d'interface pourrait être signalé par une nouvelle balise, ou par une convention du type microformat. Par exemple une balise button dont l'attribut name ressemble à "http://example.com/res1?edit".
Côté serveur, le code de la ressource ressemblerait à :
si content-type ressemble à text/html+form alors
envoyer un formulaire pré-rempli
sinon
envoyer la page habituelle
finsi
-
Les obstacles
Cette proposition demande une modification des navigateurs, et l'ajout d'un nouveau type MIME, deux choses nécessitant un large consensus parmi les développeurs et les utilisateurs.
Peut-être que d'ici là, les développeurs des principaux navigateurs auront aussi implémenté un moyen de se déconnecter après une authentification HTTP...
On peut toujours rêver :-)
# grompf
Posté par doupatex . Évalué à 1.
# euh, concrêtement ?
Posté par matthieu bollot (site web personnel, Mastodon) . Évalué à 1.
Le fait d'avoir une session/cookie peut permettre de savoir un certain nombre de choses par exemple, cela ne suffit pas ?
[^] # Re: euh, concrêtement ?
Posté par doupatex . Évalué à 3.
En fait je crois que j'étais en train de réfléchir tout haut, mais rétrospectivement ça n'est pas aussi intéressant que je le pensais ce matin...
L'intérêt serait entre autre de se passer de sessions : on fonctionne de façon "stateless", ce qui facilite la répartition de charge par exemple.
...
Mouais bof, pas très convaincant comme argument.
Pfff je suis déçu je croyais avoir trouvé un truc intéressant. Ça m'apprendra à faire des journaux :-)
Merci pour le retour sur terre. Je retourne à l'étude !
[^] # Re: euh, concrêtement ?
Posté par Joris Dedieu (site web personnel) . Évalué à 5.
non ?
# PUT -> remplacement ou création d'une ressource
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Ensuite, il me semble que le premier navigateur Web, celui utilisé par Tim Berners-Lee (le créateur du Web), et qui tournait sur NextStep, permettait de mettre à jour une ressource Web : la représentation de la ressource Web (en HTML) dans le navigateur était directement éditable. Par besoin donc de formulaire pour ce faire.
Après, il reste le problème de l'autorisation de modification de ressources Web ...
[^] # Re: PUT -> remplacement ou création d'une ressource
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
>Après, il reste le problème de l'autorisation de modification de ressources Web ...
Il y a tout ce qu'il faut dans HTTP pour s'authentifier. Après au serveur web de savoir ce que l'utilisateur authentifié a le droit de faire. Par défaut, il me semble qu'apache se base tout simplement sur les droits systèmes des fichiers. Mais mettre un autre système de droit en place est possible aussi, puisque dans apache on peut utiliser une base de donnée mysql par exemple..
M'enfin un autre problème pour l'édition : ce sont les ressources "virtuelles", celles qui ne sont pas des fichiers physiques. c'est à dire le contenu généré à la volée. Là c'est au système de gestion de contenu de prendre en charge PUT, DELETE et cie... Malheureusement, tout les modules de langages ne prennent pas forcément correctement en charge ces méthodes. Dans PHP par exemple, pour PUT, il faut parser soit même le body de la requete, alors qu'il le fait très bien pour POST. Si du multipart/form-data, il met le contenu dans $_POST et $_FILES, si c'est du urlencoded machine bidule jesaisplusquoi, il met dans $_POST etc.. Et ça il ne le fait pas pour PUT, ce qui est embétant... Il me semble aussi que l'on ne reçoit pas les requêtes HEAD (à vérifier) dans PHP.
# DAV
Posté par okparanoid . Évalué à 3.
[^] # Re: DAV
Posté par Romain . Évalué à 1.
# Pourquoi un formulaire ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Pourquoi faudrait-il absolument un formulaire ?
Un navigateur (en tout cas Firefox 3 et IE), ont des possibilités d'édition d'une page web.
1) il est possible de spécifier avec l'attribut contenteditable les élements de la page qui sont éditable (tout les navigateurs ne prennent pas encore en charge cet attribut, Firefox3 et IE le font en tout cas) http://developer.mozilla.org/En/Rich-Text_Editing_in_Mozilla
2) on active l'édition en tapant sur la touche qu'il faut (F7 dans Firefox)
3) l'utilisateur peut alors modifier les parties de la pages qui sont éditables
Il manque juste un bouton "sauver" pour sauver le contenu de la page (POST ou PUT). Il me semble que Mozilla Composer/Nvu permettent de le faire, mais à vérifier. Mais de toute façon, c'est simple à implémenter, même par le biais d'une extension (dans une extension, un coup de serialization du DOM.
Àprès, au niveau du serveur, sur un POST ou PUT, rien de plus simple que de récupèrer le contenu des éléments modifiés (tout ceux qui ont l'attribut contenteditable, avec l'aide d'un parser SAX ou DOM), et de les sauver en base dans différents champs si on veut.
Pour bien des choses, surtout quand il s'agit d'édition de contenu pure, on a utilisé les formulaire fautes de mieux. Les formulaires n'ont jamais été prévu pour ce genre d'utilisation à l'origine.
Cependant, c'est vrai que souvent les formulaires sont pratiques, surtout quand on veut limiter la saisie (afficher une listbox pour proposer des choix par ex). Mais plutôt que d'étendre le protocole HTTP, un truc plus simple serait d'implémenter un évènement dans le navigateur, qui permettrait à la page web de savoir quand est ce que l'on sort ou qu'on rentre en mode édition, et donc de permettre d'afficher/de faire disparaitre des élements de formulaire. Couplez ça avec les possibilités offline de certains navigateurs, ça peut en être sympa :-) http://developer.mozilla.org/en/Offline_resources_in_Firefox http://developer.mozilla.org/en/Online_and_offline_events
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.