Journal Éditer une ressource HTTP

Posté par  .
Étiquettes :
9
2
oct.
2008



  1. 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.





  2. 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.





  3. 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).





  4. 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




  5. 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  . Évalué à 1.

    Désolé pour le formatage, on dirait que les balises code et tt ne sont pas vraiment reconnues par le système...

  • # euh, concrêtement ?

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Je pense avoir compris le principe, mais concrêtement, dans quels cas cela serait-il suffisament important pour créer cette balise ?

    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  . Évalué à 3.

      On peut évidemment faire sans :-)
      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 !

  • # PUT -> remplacement ou création d'une ressource

    Posté par  (site web personnel) . Évalué à 2.

    Quelques éclaircissement : la méthode HTTP PUT permet de remplacer une ressource existante ou la créer avec celle embarquée dans le corps de la requête HTTP. Ce n'est pas vraiment de l'édition au sens ou tu peux ajouter ou enlever de l'information directement avec la ressource pointée par l'URI. (On peut par contre plus parler d'édition avec le navigateur, se dernier se chargeant alors de remplacer tout simplement le contenu existant avec le nouveau avec la méthode PUT ; enfin s'il supporte cette fonction.)

    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  (site web personnel, Mastodon) . Évalué à 3.

      Amaya aussi permet l'édition de pages distantes et sait faire du PUT, DELETE et cie.

      >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  . Évalué à 3.

    Pas sur d'avoir bien saisi le probleme mais t'es sur que le protocole dav n'y repond pas ?!

    • [^] # Re: DAV

      Posté par  . Évalué à 1.

      Ce qu'il dit justement c'est que les navigateurs pourraient supporter ce protocole.

  • # Pourquoi un formulaire ?

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    > 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.

    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.