web-dev-qa-db-fra.com

Pourquoi n'y a-t-il pas de méthodes PUT et DELETE sur les formulaires HTML?

HTML4/XHTML1 n'autorise que GET et POST dans les formulaires, il semble maintenant que HTML5 fera de même. Il y a ne proposition à ajouter ces deux mais il ne le fait pas semblent gagner du terrain. Quelles étaient les raisons techniques ou politiques pour ne pas inclure PUT et DELETE dans le projet de spécification HTML5?

htmlhtml5
281
FilipK

C'est une question fascinante. Les autres réponses ici sont toutes spéculatives et, dans certains cas, carrément incorrectes. Au lieu d'écrire mon opinion ici, j'ai en fait fait des recherches et trouvé des sources originales qui expliquent pourquoi supprimer et put ne font pas partie de la norme de formulaire HTML5.

Il s'avère que ces méthodes étaient incluses dans plusieurs versions préliminaires HTML5 (!), Mais ont ensuite été supprimées dans versions ultérieures . Mozilla avait en fait implémenté cela dans une version bêta de Firefox , aussi.

Quelle était la justification de la suppression de ces méthodes du projet? Le W3C a discuté de ce sujet dans rapport de bogue 10671 . Mike Amundsen a plaidé en faveur de ce soutien:

L'exécution de PUT et DELETE pour modifier des ressources sur le serveur Origin est simple pour les navigateurs Web modernes utilisant l'objet XmlHttpRequest. Pour les interactions de navigateur non scriptées, ce n'est pas si simple. [...]

Ce modèle est si souvent requis que plusieurs frameworks/bibliothèques Web couramment utilisés ont créé une solution de contournement "intégrée". [...]

Autres considérations:

  • L'utilisation de POST comme tunnel au lieu d'utiliser PUT/DELETE peut entraîner des correspondances incorrectes de mise en cache (par exemple POST sont cachable , Les réponses PUT ne sont pas (6), les réponses DELETE ne le sont pas (7))
  • L'utilisation d'une méthode non idempotente (POST) pour effectuer une opération idempotente (PUT/DELETE) complique la récupération en raison de pannes de réseau (par exemple, "Est-il sûr de répéter cette action?").
  • [...]

Cela vaut la peine de lire l'intégralité de son article.

Tom Wardrop fait également une remarque intéressante:

HTML est inextricablement lié à HTTP. HTML est l'interface humaine de HTTP. On peut donc automatiquement se demander pourquoi HTML ne prend pas en charge toutes les méthodes pertinentes dans la spécification HTTP. Pourquoi les machines peuvent-elles METTRE et SUPPRIMER des ressources, mais pas les humains? [...]

Il est contradictoire que, bien que le HTML se donne beaucoup de mal pour garantir le balisage sémantique, il n'a jusqu'à présent fait aucun effort pour garantir les requêtes HTTP sémantiques.

Le bogue a finalement été fermé sous la forme Won't Fix par Ian Hickson, avec la justification suivante:

PUT en tant que méthode de formulaire n'a aucun sens, vous ne voudriez pas mettre une charge utile de formulaire. SUPPRIMER n'a de sens que s'il n'y a pas de charge utile, donc cela n'a pas beaucoup de sens avec les formulaires non plus.

Mais ce n'est pas la fin de l'histoire! Le problème a été résolu dans le suivi des bogues du W3C et escaladé au suivi des problèmes du groupe de travail HTML:

https://www.w3.org/html/wg/tracker/issues/195

À ce stade, il semble que la principale raison pour laquelle ces méthodes ne sont pas prises en charge est simplement que personne n'a pris le temps de rédiger une spécification complète pour elle.

370
Mark E. Haase

Cela a été soulevé en 2010 comme le bogue 10671 envisage d'ajouter la prise en charge de PUT et DELETE en tant que méthodes de formulaire .

Il y avait une quantité modérée de recul pour cette "fonctionnalité" et une certaine lourdeur mais finalement cela a été escaladé comme deux problèmes sur le suivi des bogues des groupes de travail:

Le problème ISSUE-196 a abouti à une décision consensuelle de n'apporter aucun changement à la spécification car la spécification HTML ne limite pas actuellement la façon dont les réponses aux requêtes POST sont traitées. I Je crois que ce problème particulier a été soulevé en essayant de réconcilier POST modèles de redirection couramment utilisés et comment les serveurs ReSTful fournissent souvent des réponses 2xx avec des messages courts plutôt que quelque chose d'utile à afficher dans un navigateur.

La question NUMÉRO-195 a été présentée aux présidents. Cameron Jones s'est porté volontaire pour rédiger une proposition de changement le 18 janvier 2012 qu'il a soumise pour devenir le premier projet de travail le 29 mai 2014. Le projet passera par le W3C processus de recommandations .

Avec un peu de chance, cela deviendra bientôt une recommandation du W3C et mis en œuvre par les fournisseurs de navigateurs, et serait un grand pas en avant dans la suppression des bloqueurs pour produire des services ReSTful unifiés, sémantiques et conviviaux pour les navigateurs. J'imagine que cela va spark une évolution intéressante dans les modèles de service. Il y a un bon discours de Jon Moore - Hypermedia APIs mérite d'être regardé, cela a suscité mon intérêt mais est tombé à la premier obstacle (celui-ci).

13
Stuart Wakefield

GET et POST ont une justification claire et neutre en termes de contenu. GET consiste à récupérer le contenu d'une URL d'une manière qui peut être répétée et éventuellement mise en cache. POST = consiste à faire quelque chose d'une manière qu'il n'est pas sûr de répéter, d'exécuter de manière spéculative ou de mettre en cache.

Il n'y avait pas de justification similaire pour PUT ou DELETE. Ils sont tous deux entièrement couverts par POST. La création ou la destruction d'une ressource sont des opérations qui ne sont pas sûres à répéter, pas sûres à exécuter de manière spéculative et ne doivent pas être mises en cache. Aucune sémantique spéciale supplémentaire n'est nécessaire pour eux.

Donc, fondamentalement, il n'y a aucun avantage.

12
David Schwartz

Ma compréhension est que les navigateurs ne savent pas quoi faire une fois qu'ils ont envoyé un PUT ou un DELETE. A POST redirigera généralement vers une page appropriée, mais PUT et DELETE ne le font généralement pas. Cela les rend appropriés pour appeler via ajax ou un programme natif, mais pas à partir d'un formulaire de navigateur Web.

Je ne peux pas le faire pour l'instant, mais je me souviens avoir lu l'une des listes de diffusion html5 quand ils en discutaient.

5
maxpolun

Histoire

Je pense qu'il vaut la peine de mentionner la première apparition de formulaires html dans le RFC1866 (Section 8.1) . Ici, l'attribut de méthode est défini comme suit:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Des explications supplémentaires se trouvent dans Section 8.2.2 - GET et Section 8.2.3 - POST

Gardez à l'esprit que HTML 2.0 (novembre 1995) a été spécifié avant HTTP 1. (mai 1996). Donc tout le monde n'utilisait HTTP qu'avec GET (à partir de HTTP 0.9) ou avec l'extension POST. Mais seuls quelques serveurs Web prennent en charge PUT et DELETE (comme indiqué dans le Annexe HTTP 1. ).

Pensées

Si vous pensez à la façon dont le développement du Web sémantique par Berners-Lee aurait pu évoluer, il semble clair qu'il est passé de problèmes réels à un concept général. Il a d'abord voulu partager des documents. Il avait donc besoin d'un balisage. Puis il a voulu interroger les bases de données pour le contenu, il avait donc besoin de formulaires. Il a ensuite voulu mettre de nouvelles données dans la base de données. Il a donc utilisé des formulaires avec GET et POST. Après cela, il s'est peut-être rendu compte que vous pouviez effectuer toutes les opérations CRUD sur des données à distance, donc HTTP a été étendu mais jamais HTML car il était trop tard (seuls quelques serveurs prenaient en charge les nouvelles opérations CRUD).

5
schmijos