Quel est le besoin de méthodes comme GET et POST dans le protocole HTTP?

Ne pouvons-nous pas implémenter le protocole HTTP en utilisant simplement un corps de requête et un corps de réponse?

Par exemple, l'URL contiendra une requête, qui sera mappée à une fonction en fonction du langage de programmation côté serveur, par exemple un servlet et en réponse, une réponse HTML et JavaScript sera envoyée.

Pourquoi le protocole HTTP a-t-il une notion de méthodes?

À partir des réponses, j'ai une idée de la raison pour laquelle le concept de méthodes existe. Cela conduit à une autre question connexe:

Par exemple, dans le lien de composition gmail, la demande PUT / POST et les données seront envoyées. Comment le navigateur parvient-il à savoir quelle méthode utiliser? La page gmail envoyée par le serveur inclut-elle le nom de la méthode à utiliser lors de l'appel à la demande de composition gmail? lorsque nous appelons www.gmail.com, il doit utiliser la méthode GET, comment le navigateur sait-il que cette méthode doit être utilisée?

PS : Je n'ai pas assez de crédits pour commenter les réponses, donc je ne suis pas en mesure de commenter de nombreuses questions soulevées par des personnes liées à l'intention derrière cette question.

Comme certaines réponses le disent, nous pouvons créer de nouveaux utilisateurs sur la méthode DELETE, ce qui soulève la question de l'intention derrière la notion de méthodes dans le protocole http, car en fin de compte, cela dépend totalement des serveurs à quelle fonction ils veulent mapper une URL. . Pourquoi le client devrait-il indiquer aux serveurs les méthodes à utiliser pour une URL?

Veuillez noter que la question a changé / a été clarifiée depuis que cette réponse a été écrite pour la première fois. Une autre réponse à la dernière itération de la question est après la deuxième règle horizontale

Quel est le besoin de méthodes comme GET et POST dans le protocole HTTP?

Ils, avec quelques autres choses comme les formats d'en-tête, les règles de séparation des en-têtes et des corps, forment la base du protocole HTTP

Ne pouvons-nous pas implémenter le protocole HTTP en utilisant simplement un corps de requête et un corps de réponse?

Non, car tout ce que vous avez créé ne serait pas le protocole HTTP

Par exemple, l'URL contiendra une requête, qui sera mappée à une fonction en fonction du langage de programmation côté serveur, par exemple un servlet et en réponse, une réponse HTML et JavaScript sera envoyée.

Félicitations, vous venez d'inventer un nouveau protocole! Maintenant, si vous voulez mettre en place un organisme de normalisation pour le conduire et le maintenir, le développer, etc., il pourrait dépasser HTTP un jour

J'apprécie que c'est un peu ironique, mais il n'y a rien de magique sur Internet, TCP / IP ou la communication qui se fait entre les serveurs et les clients. Vous ouvrez une connexion et envoyez quelques mots sur le fil, formant une conversation. La conversation doit vraiment adhérer à certaines spécifications ratifiées aux deux extrémités si les demandes doivent être comprises et des réponses sensées fournies. Ce n'est pas différent de n'importe quel dialogue dans le monde. Vous parlez anglais, votre voisin parle chinois. J'espère que votre main agitant, pointant et secouant le poing sera suffisante pour transmettre votre message que vous ne voulez pas qu'il stationne sa voiture devant votre maison.

De retour sur Internet, si vous ouvrez un socket sur un serveur Web compatible HTTP et envoyez ce qui suit:

EHLO
AUTH LOGIN

(Le début d'une transmission d'email SMTP) alors vous n'obtiendrez pas de réponse sensée. Vous pouvez créer le client compatible SMTP le plus parfait, mais votre serveur Web ne lui en parlera pas car cette conversation concerne le protocole partagé - pas de protocole partagé, pas de joie.

C'est pourquoi vous ne pouvez pas implémenter le protocole HTTP sans implémenter le protocole HTTP; si ce que vous écrivez n'est pas conforme au protocole, alors ce n'est tout simplement pas le protocole - c'est autre chose, et cela ne fonctionnera pas comme spécifié dans le protocole

Si nous courons avec votre exemple pendant un moment; où le client se connecte et déclare simplement quelque chose qui ressemble à une URL .. Et le serveur le comprend et envoie simplement quelque chose qui ressemble à HTML / JS (une page Web) alors bien sûr, cela pourrait fonctionner. Qu'avez-vous sauvé cependant? Quelques octets pour ne pas dire GET? Moins sur l'abandon de ces embêtants embêtants .. Le serveur en a également enregistré - mais que faire si vous ne pouvez pas déterminer ce qu'il vous a envoyé? Et si vous demandiez une URL qui se terminait en JPEG et qu'elle vous envoyait des octets qui font une image, mais c'est en PNG? Un PNG incomplet à cela. Si seulement nous avions un en-tête qui disait combien d'octets ça allaitpour envoyer, nous saurions alors si le nombre d'octets que nous avons reçu était en fait le fichier entier ou non. Et si le serveur compressait la réponse pour économiser de la bande passante sans vous le dire? Vous allez dépenser une puissance de calcul considérable pour essayer de comprendre ce qu'il a envoyé.

À la fin de la journée, nous avons besoin de métainformation - informations sur l'information; nous avons besoin d'en-têtes; nous avons besoin de fichiers pour avoir des noms, des extensions, des dates créées. Nous avons besoin que les gens fêtent leurs anniversaires, pour dire s'il vous plaît et merci, etc. - le monde est plein de protocoles et d'informations sur le contexte, nous n'avons donc pas à nous asseoir et à tout travailler à partir de zéro tout le temps. Cela coûte un peu d'espace de stockage, mais cela en vaut facilement la peine

L'implémentation de diverses méthodes HTTP est-elle vraiment nécessaire?

Sans doute, il n'est pas nécessaire d'implémenter l'intégralité du protocole spécifié, et cela est généralement vrai pour tout. Je ne connais pas tous les mots de la langue anglaise; mon voisin chinois est également développeur de logiciels mais dans une industrie différente et il ne connaît même pas le chinois pour certains des termes utilisés dans mon industrie et encore moins l'anglais. La bonne chose est que nous pouvons tous les deux récupérer un document sur la mise en œuvre de HTTP, il peut écrire le serveur et je peux écrire le client, dans différents langages de programmation sur différentes architectures, et ils fonctionnent toujours parce qu'ils adhèrent au protocole

Il se pourrait bien qu'aucun de vos utilisateurs n'émette autre chose qu'une demande GET, n'utilisera pas de connexions persistantes, n'enverra rien d'autre que JSON comme corps, ou devra accepter autre chose que text / plain pour que vous puissiez écrire un serveur Web vraiment épuré qui ne répond qu'aux exigences très limitées du navigateur client. Mais vous ne pouviez pas simplement décider arbitrairement de supprimer les règles de base qui font de "certains textes passant par une socket" ce qu'est HTTP; vous ne pouvez pas abandonner l'idée de base que la demande sera une chaîne comme:

VERB URL VERSION
header: value

maybe_body

Et la réponse aura une version, un code d'état et peut-être des en-têtes. Si vous changez tout cela - ce n'est plus HTTP - c'est autre chose et ne fonctionnera qu'avec quelque chose qui est conçu pour le comprendre. HTTP est ce qu'il est par ces définitions, donc si vous voulez l'implémenter, vous devez suivre les définitions

Mise à jour

Votre question a un peu évolué, voici une réponse à ce que vous demandez:

Pourquoi le protocole HTTP a-t-il une notion de méthodes?

Historiquement, vous devez comprendre que les choses étaient beaucoup plus rigides dans leur conception et leur implémentation, même dans la mesure où les scripts n'existaient pas et même la notion que les pages pouvaient être dynamiques, générées à la volée en mémoire et enfoncées à la place. d'être un fichier statique sur le disque qui a été demandé par le client et lu et poussé vers le bas du socket, n'existait pas. En tant que tel, le tout début du Web était centré sur la notion de pages statiques contenant des liens vers d'autres pages, toutes les pages existaient sur le disque et la navigation aurait été effectuée par le terminal effectuant principalement des requêtes GET pour les pages des URL, le serveur serait en mesure de mapper l'url vers un fichier sur le disque et l'envoyer. Il y avait aussi cette notion selon laquelle le réseau de documents liés entre eux et ailleurs devait être une évolution,

Cela donne un certain contexte historique pour les méthodes - il était une fois que l'URL était le bit inflexible et renvoyait de manière simplifiée aux pages sur le disque, la méthode était donc utile car elle permettait au client de décrire son intention pour le fichier et le serveur le ferait. traiter la méthode d'une manière variable. Il n'y avait pas vraiment de notion d'URL virtuelle ou utilisée pour changer ou mapper dans la vision originale d'un hypertexte (et c'était vraiment du texte uniquement) web

Je n'ai pas l'intention que cette réponse soit une documentation de l'historique avec des dates et des références citées de quand exactement les choses ont commencé à changer - pour cela, vous pouvez probablement lire Wikipedia - mais il suffit de dire qu'avec le temps, le désir de Web pour être plus dynamique et à chaque extrémité de la connexion serveur-client les opportunités de créer une expérience multimédia riche que nous élargissons. Les navigateurs ont pris en charge une énorme prolifération de balises pour formater le contenu, chacun se précipitant pour mettre en œuvre des fonctionnalités de richesse multimédia incontournables et de nouvelles façons de rendre les choses plus élégantes.

Les scripts sont arrivés du côté client et les plug-ins et extensions de navigateur, tous destinés à faire du navigateur une puissante centrale de tout. Au niveau du serveur, la génération active de contenu basé sur des algorithmes ou des données de base de données a été la grande poussée et continue de se développer dans la mesure où il y a probablement peu de fichiers sur le disque - bien sûr, nous conservons une image ou un fichier de script en tant que fichier sur le serveur Web et le navigateur l'obtiennent, mais de plus en plus les images que le navigateur affiche et les scripts qu'il exécute ne sont pas des fichiers que vous pouvez ouvrir dans votre explorateur de fichiers, ils sont du contenu généré qui est la sortie d'un processus de compilation effectué à la demande , SVG qui décrit comment dessiner des pixels plutôt qu'un tableau bitmap de pixels, ou JavaScript qui a été émis à partir d'une forme de script de niveau supérieur comme TypeScript

En créant des pages modernes de plusieurs mégaoctets, seule une fraction d'entre elles est probablement un contenu fixe sur un disque; les données de la base de données sont formatées et façonnées en html que le navigateur consommera et elles sont effectuées par le serveur en réponse à plusieurs routines de programmation différentes référencées d'une manière ou d'une autre par l'url

J'ai mentionné dans les commentaires à la question que c'est un peu comme un cercle complet. À l'époque où les ordinateurs coûtaient des centaines de milliers et remplissaient des salles, il était courant d'autoriser plusieurs utilisateurs à utiliser le seul ordinateur central central super puissant au moyen de centaines de terminaux stupides - un clavier et une souris, un écran vert, envoyer du texte, en obtenir texte. Au fil du temps, à mesure que la puissance de calcul augmentait et que les prix baissaient, les gens ont commencé à se retrouver avec des ordinateurs de bureau plus puissants que les premiers mainframes et à pouvoir exécuter des applications puissantes localement, de sorte que le modèle mainframe est devenu obsolète. Cela n'a jamais disparu, car les choses ont simplement évolué pour changer de direction et revenir un peu à un serveur central fournissant la plupart des fonctionnalités d'application utiles et une centaine d'ordinateurs clients qui font très peu sauf dessiner sur l'écran, et soumettre et recevoir des données vers / depuis le serveur. Cette période intermédiaire où votre ordinateur était suffisamment intelligent pour exécuter sa propre copie de Word et Outlook en même temps a de nouveau cédé la place au bureau en ligne, où votre navigateur est un appareil pour dessiner des images à l'écran et modifier le document / e-mail que vous '' réécrire comme une chose qui vit sur le serveur, y est enregistré, envoyé et partagé avec d'autres utilisateurs, tout comme la notion que le navigateur n'est qu'un shell qui fournit à tout moment une vue partielle de cette chose qui vit ailleurs

À partir des réponses, j'ai une idée de la raison pour laquelle le concept de méthodes existe. Cela conduit à une autre question connexe:

Par exemple, dans le lien de composition gmail, la demande PUT / POST et les données seront envoyées. Comment le navigateur parvient-il à savoir quelle méthode utiliser?

Il utilise GET par défaut, par convention / spécification car c'est ce qui est décrété doit se produire lorsque vous tapez une URL et appuyez sur Retour

La page gmail envoyée par le serveur inclut-elle le nom de la méthode à utiliser lors de l'appel à la demande de composition gmail?

C'est l'une des principales choses auxquelles je fais allusion dans les commentaires ci-dessus. Dans le Web moderne, il ne s'agit même plus de pages. Une fois que les pages étaient des fichiers sur le disque, le navigateur OBTIENDRAIT. Ensuite, ils sont devenus des pages qui ont été principalement générées dynamiquement en insérant des données dans un modèle. Mais cela impliquait toujours un processus "demander une nouvelle page au serveur, obtenir une page, afficher la page". L'échange de pages est devenu très simple; vous ne les avez pas vus charger et redimensionner et déplacer leur mise en page de manière à ce qu'elle soit plus fluide, mais c'était toujours le navigateur qui remplaçait une page entière ou une partie d'une page par une autre

La façon moderne de faire les choses consiste à utiliser une application d'une seule page; le navigateur a un document en mémoire qui s'affiche d'une certaine manière, le script appelle le serveur et récupère quelques pépites d'informations, et manipule le document de sorte qu'une partie de la page change visuellement pour afficher les nouvelles informations - tout fonctionne sans le navigateur chargeant jamais une autre nouvelle page; c'est juste devenu une interface utilisateur dont certaines parties sont mises à jour comme une application cliente typique comme Word ou Outlook. De nouveaux éléments apparaissent au-dessus d'autres éléments et peuvent être glissés dans les fenêtres de dialogue de simulation, etc. Tout cela est le moteur de script du navigateur qui envoie des demandes à l'aide de la méthode http souhaitée par le développeur, récupère les données et fouille le document que le navigateur dessine. Vous pouvez concevoir que le navigateur moderne est un appareil brillant qui ressemble à tout un système d'exploitation ou à un ordinateur virtuel; un appareil programmable qui a une façon assez standardisée de dessiner des choses à l'écran, de jouer du son, de capturer les entrées de l'utilisateur et de les envoyer pour traitement. Tout ce que vous avez à faire pour dessiner votre interface utilisateur est de lui fournir du html / css qui crée une interface utilisateur, puis de modifier constamment le html pour que le navigateur modifie ce qu'il dessine. Heck, les gens sont tellement habitués à voir la barre d'adresse changer / l'utiliser comme une direction d'intention qu'une application d'une seule page changera l'URL par programme même si aucune navigation (demander de nouvelles pages entières) n'est en cours Tout ce que vous avez à faire pour dessiner votre interface utilisateur est de lui fournir du html / css qui crée une interface utilisateur, puis de modifier constamment le html pour que le navigateur modifie ce qu'il dessine. Heck, les gens sont tellement habitués à voir la barre d'adresse changer / l'utiliser comme une direction d'intention qu'une application d'une seule page changera l'URL par programme même si aucune navigation (demander de nouvelles pages entières) n'est en cours Tout ce que vous avez à faire pour dessiner votre interface utilisateur est de lui fournir du html / css qui crée une interface utilisateur, puis de modifier constamment le html pour que le navigateur modifie ce qu'il dessine. Heck, les gens sont tellement habitués à voir la barre d'adresse changer / l'utiliser comme une direction d'intention qu'une application d'une seule page changera l'URL par programme même si aucune navigation (demander de nouvelles pages entières) n'est en cours

lorsque nous appelons www.gmail.com, il doit utiliser la méthode GET, comment le navigateur sait-il que cette méthode doit être utilisée?

Vrai. Parce que c'est spécifié. La première demande est comme cela a toujours été le cas - OBTENEZ du code HTML initial pour dessiner une interface utilisateur, puis piquez-le et manipulez-le pour toujours, ou obtenez une autre page avec un autre script qui pique et manipule et crée une interface utilisateur réactive réactive

Comme certaines réponses le disent, nous pouvons créer de nouveaux utilisateurs sur la méthode DELETE, ce qui soulève la question de l'intention derrière la notion de méthodes dans le protocole http, car en fin de compte, cela dépend totalement des serveurs à quelle fonction ils veulent mapper une URL. . Pourquoi le client devrait-il indiquer aux serveurs les méthodes à utiliser pour une URL?

Histoire. Héritage. Nous pourrions théoriquement supprimer toutes les méthodes http demain - nous sommes à un niveau de sophistication de la programmation où les méthodes sont obsolètes car les URL sont traitables dans la mesure où elles peuvent être le mécanisme de commutation qui indique au serveur que vous souhaitez enregistrer les données dans le corps en tant que brouillon d'e-mail, ou supprimez un brouillon - il n'y a pas de fichier / emails / brouillon / enregistrer / 1234 sur le serveur - le serveur est programmé pour séparer cette URL et savoir quoi faire avec les données du corps - enregistrer comme un projet d'e-mail sous l'ID 1234

Il est donc certainement possible de supprimer les méthodes, à l'exception du poids énorme de la compatibilité héritée qui a grandi autour d'eux. Il est préférable de les utiliser pour ce dont vous avez besoin, mais de les ignorer en grande partie et d'utiliser à la place tout ce dont vous avez besoin pour que votre truc fonctionne. Nous avons encore besoin de méthodes telles que spécifiées, car vous devez vous rappeler qu'elles signifient quelque chose pour le navigateur et le serveur sur lesquels nous avons créé nos applications. Le script côté client veut utiliser le navigateur sous-jacent pour envoyer des données, il doit utiliser une méthode qui fera faire au navigateur ce qu'il demande - probablement un POST parce que GET emballe toutes ses informations variables dans l'url et qui a une limite de longueur dans beaucoup de serveurs. Le client veut une longue réponse du serveur - n'utilisez pas de HEAD car ils ne sont pas censés avoir du tout de corps de réponse.

HTTP peut être considéré comme un cas spécifique des principes génériques de l'appel de procédure à distance: vous dites au serveur ce que vous voulez avec un champ variable dans la demande, le serveur répond en conséquence. À l'heure actuelle, en raison de l'interactivité complexe du `` Web 2.0 '', ces mêmes fonctionnalités sont intégrées dans tous les domaines de la demande: l'URL, les en-têtes, le corps - et chaque serveur d'applications et applications les comprend à leur manière. Cependant, à l'origine, le Web était plus simple, utilisait des pages statiques et on pensait que les méthodes HTTP fournissaient le niveau d'interactivité suffisant. Notamment, HTTP dispose de nombreuses méthodes qui sont rarement, voire jamais, certaines d'entre elles ne voyant le jour que grâce à REST. Par exemple, PUT et DELETE étaient moribonds avant REST, et TRACE et PATCH sont toujours invisibles. La conclusion est que le modèle HTTP de RPC n'a pas

REST a fait exactement le contraire de ce que vous proposez, en notant que les méthodes HTTP servent les cas d'utilisation CRUD typiques de la plupart des applications si PUT et DELETE sont rétablis.

Notez également que les méthodes HTTP ont une sémantique qui leur est affectée, qui sont honorées par les navigateurs et les middlewares comme les serveurs proxy: les requêtes POST, PUT, DELETE et PATCH peuvent avoir des effets secondaires et ne pas être idempotentes, donc les applications côté client et les middlewares font attention de ne pas déclencher ces demandes sans action expresse de l'utilisateur. Dans la pratique, les applications Web mal conçues utilisaient GET pour des actions non sûres, et par exemple le préfiltre Google Web Accelerator a causé des problèmes en supprimant un tas de données sur ces sites , de sorte que sa version bêta a été suspendue peu de temps après le lancement.

Donc, pour répondre à la question «pouvons-nous»: bien sûr, il vous suffit de vous mettre d'accord sur un protocole qui indiquera à l'application serveur l'action que vous souhaitez effectuer, puis vous placez les arguments quelque part dans l'URL / le corps, tels que le élément cible pour l'action. L'ensemble d'actions est limité uniquement par des applications spécifiques, vous avez donc besoin d'un protocole extensible. Mais vous devrez informer les applications clientes des demandes qui sont sûres et probablement prendre en compte d'autres nuances, telles que le contrôle du cache.

De mon point de vue personnel en tant que développeur, cela peut faciliter la création de points de terminaison API. Par exemple, si j'écris un contrôleur qui gère les produits sur un site Web, je peux utiliser la même URL pour effectuer plusieurs opérations différentes.

Exemples:

GET https://example.com/api/products/1234

Cela va chercher les détails du produit 1234.

POST https://example.com/api/products/1234

Cela créera un produit avec l'ID 1234 en utilisant les données dans le corps de la demande.

PUT https://example.com/api/products/1234

Cela mettra à jour le produit 1234 avec des données dans le corps de la demande.

DELETE https://example.com/api/products/1234

Cela supprimera un produit avec l'ID 1234.

Je pourrais créer différents points de terminaison pour chaque opération, mais cela compliquerait le processus et le rendrait moins compréhensible pour les autres développeurs.

Quel est le besoin de méthodes comme GET et POST dans le protocole HTTP?

Il semble que vous ayez oublié l'ancien temps où les serveurs HTTP n'étaient là que pour servir des fichiers ; ne pas exécuter de script, CGI ou créer un contenu dynamique de ce type.

Les méthodes de demande sont des verbes normalisés de base sur ce qu'il faut faire avec ces fichiers ...

• GET signifie télécharger
• HEAD signifie obtenir des informations sur
• PUT signifie upload
• SUPPRIMER signifie supprimer
• POST signifie envoyer des données dans
• OPTIONS signifie me dire ce que je pourrais faire

Au jour de HTTP / 0.9, la ligne de demande est la seule chose dans la jambe de demande du protocole; aucun en-tête de demande, aucun en-tête de réponse. Vous tapez simplement GET /somefile, appuyez sur Enter, le serveur renverra le corps de la réponse (c'est-à-dire le contenu HTML), et merci au revoir (c'est-à-dire fermer la connexion).

Si vous vouliez simplement demander pourquoi il a été conçu de cette façon ? Ma réponse est parce qu'il a été écrit à l' origine pour gérer le type d'échange de contenu qui existait à l'époque , c'est-à-dire le service de fichiers HTML statiques à la demande des utilisateurs.

Cependant, si vous vouliez savoir comment traiter cette sémantique dans un serveur d'applications moderne ...

Ne pouvons-nous pas implémenter le protocole HTTP en utilisant simplement un corps de requête et un corps de réponse?

L'implémentation de diverses méthodes HTTP est-elle vraiment nécessaire?

Ma réponse est: faites ce que vous voulez faire, mais gardez à l'esprit que vous ne devez pas implémenter la logique d'application d'une manière qui défie les attentes du protocole : les attentes comme GET ne devraient pas changer les données (ou très lâchement, avoir au moins un résultat idempotent ), HEAD devrait avoir le même résultat que GET mais sans corps de réponse, PUT devrait rendre le contenu de l'URI cible disponible (en cas de réussite).

Si vous allez à l'encontre des attentes sans considérer attentivement ses implications , diverses choses désagréables se produiraient, comme ...

• Lorsque vous introduisez la méthode GET dans l'utilisation de la soumission de données, le serveur peut vous cracher une erreur 414 " URI trop longue ".
• Lorsque vous chaussez la méthode GET dans l'utilisation de la modification des données, vous constaterez que la modification ne passe parfois pas lorsque l'utilisateur est derrière un proxy de mise en cache, ou des modifications inattendues ont lieu lorsque l'utilisateur rappelle l'URL du signet (ou lorsque les robots Web l'atteignent) .
• Lorsque vous répondez à la méthode HEAD de manière incorrecte, vous constaterez que vos outils de vérification automatique du site (par exemple wget --spider) sont mis en liberté sur votre site.
• Lorsque vous chaussez la méthode POST dans le téléchargement de contenu, vous constaterez que le signet ou même la saisie de l'URL dans le navigateur ne fonctionnera pas.
• Et beaucoup plus...

"Le débutant connaît les règles, mais les vétérans connaissent les exceptions. "

Quoi qu'il en soit, vous pourriez finir par trouver des excuses valables pour aller à l'encontre de certaines règles pour certains cas d'utilisation étroits; mais assurez-vous de faire vos recherches et d'envisager toutes les possibilités. Sinon, vous allez finir par interrompre l'interopérabilité et ruiner les «expériences utilisateur».

Il n'y a aucune garantie que les utilisateurs utilisent toujours le dernier déploiement brillant de clients / agents utilisateurs de marque que vous avez testés. Ils peuvent utiliser une marque locale adaptée à leurs besoins (moi inclus), une marque personnalisée qu'ils ont commandée dans un magasin spécialisé à côté ou une marque vintage qu'ils ont extraite d'un cellier. Même avec tout cela, vos sites devraient toujours fournir un service raisonnable. C'est une raison pour laquelle nous avons des normes.

Briser négligemment la norme signifie également que vous appliquez une discrimination à vos utilisateurs.

Il est vrai qu'en théorie, nous pourrions utiliser partout et cela fonctionnerait en quelque sorte. Certains logiciels utilisent même GET avec le corps de la requête (je vous regarde elasticsearch / kibana). Bien sûr, c'est une chose horrible à faire.

La raison la plus importante est que les différentes méthodes ont une sémantique différente. Certains sont sûrs, certains sont idempotents. Certains sont les deux. Voir quels sont quels

Ceci est important, par exemple lors de l'interaction avec d'autres applications. Les points d'extrémité GET ne sont pas censés avoir d'effets secondaires. Ceci est important lorsque Google rampe à vos côtés. PUT est censé être idempotent, ce qui signifie que le client est libre de réessayer en cas d'échec. Ce n'est pas le cas pour POST, ce qui explique pourquoi les navigateurs doivent avoir une boîte de confirmation laide si vous appuyez sur f5 lors d'une demande de publication.

Découvrez ce qui peut arriver si vous utilisez GET là où vous auriez dû utiliser POST

Vous pouvez également considérer GET, POST, etc. comme des surcharges de la même fonction, ou même comme des getters et des setters.

GET_MyVar() ne prendra pas de paramètre d'entrée (alias le corps de la demande), mais renvoie quelque chose.

POST_MyVar(string blah)fait quelque chose avec l'entrée (encore une fois, le corps de la demande) et peut retourner quelque chose. (Il doit également renvoyer au moins un code de réponse, afin que nous sachions que la fonction a fonctionné !!)

DELETE_MyVar() Aussi ne prend probablement rien et devrait supprimer quelque chose.

Oui, nous pourrions tout mettre en œuvre avec:
MyVar(string Action, string? blah)

De cette façon, nous pourrions accepter un seul appel, puis choisir quoi faire en fonction d'un autre paramètre.

Mais l'une des commodités de cette approche est qu'elle permet aux navigateurs et aux serveurs d'optimiser la façon dont ces choses fonctionnent. Par exemple, le serveur voudra peut-être bloquer toutes les demandes où Action==DELETE. Peut-être que les navigateurs veulent mettre en cache des choses où Action==GET.sinon, dans chaque fonction, nous aurions à écrireif (Action==Delete) {return AngryFace}

Il n'est pas nécessaire de tout mettre en œuvre exactement selon le protocole, mais le protocole est essentiellement un ensemble de règles que nous avons tous décidé de suivre. De cette façon, je devine facilement ce que fera votre site, même si je n'ai pas vu le serveur!

Les méthodes HTTP ont des objectifs différents. En général, GETc'est pour les téléchargements et POSTpour les téléchargements.

La seule façon d'implémenter une partie du protocole HTTP en utilisant uniquement un corps de requête et un corps de réponse serait de l'implémenter POST. GETn'a pas d'organe de demande. Il n'a que la demande elle-même avec des en-têtes, mais pas de corps. Il s'agit simplement d'une demande de téléchargement d'un document. POSTa à la fois le corps de la demande (le téléchargement de fichier) et un corps de réponse (le document montrant le résultat).

Pourriez-vous simplement mettre en œuvre POSTet être fait? Pas si vous voulez que votre site soit utilisable dans les navigateurs standard. Le type de demande par défaut que les navigateurs envoient est GET. POSTles demandes ne sont généralement envoyées que lorsque les formulaires des pages Web sont soumis ou pour les appels AJAX. Ce n'est que si ce serveur particulier était utilisé uniquement pour les appels AJAX, et non pour les pages visibles par les utilisateurs, que vous pourrez vous en sortir POSTuniquement.

Les navigateurs envoient également parfois des HEADdemandes pour vérifier si un document a changé depuis la dernière fois qu'ils l'ont téléchargé, il serait donc conseillé de le mettre en œuvre au moins également.

Dans tous les cas, il n'y a pas de bonne raison d'implémenter un serveur Web à partir de zéro. Le protocole HTTP est compliqué. En plus des différentes méthodes, vous devrez également implémenter le pipelining et les requêtes fragmentées. Il est beaucoup plus facile de créer votre application Web sur un serveur Web comme Apache, Nginx ou IIS qui gère le protocole HTTP pour vous. Vous mentionnez les servlets, alors vous devriez peut-être utiliser les serveurs Web Tomcat ou JBoss qui exécutent les servlets.

Vous avez raison, nous pourrions faire exactement cela, GET, POST, PUT, etc. ne sont que des conventions historiques si j'avais mon chemin HTTP serait remplacé par juste la méthode POST et rien d'autre, même si je dois concéder que l'élimination de GET serait une entreprise énorme, cela ne pouvait pas être fait, le cheval a déjà boulonné sur celui-là

Votre protocole proposé serait considérablement moins sécurisé contre les pirates.

Il y a une raison pour laquelle les sites Web ont abandonné le stockage d'informations sur les variables et autres dans l'URL, et cette raison est simple: cela donne aux attaquants un moyen très simple d'attaquer votre système. En observant les informations d'URL en texte brut, ils peuvent déterminer la façon dont les données envoyées à votre serveur Web sont construites; ils peuvent ensuite utiliser ces informations pour exécuter une attaque sur votre serveur en utilisant une URL spécialement conçue qui leur permet d'injecter du code ou des données malveillants sur votre serveur.