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 demande, 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 posées par des personnes liées à 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 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 demande, 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 des 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é? Que se passe-t-il si vous demandez une URL qui se termine en JPEG et que cela vous envoie 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 ( allait envoyer, alors nous saurions 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 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 l'implémentation 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 demandes GET pour les pages des URL, le serveur pourrait mapper l'url vers un fichier sur le disque et l'envoyer. Il y avait aussi cette notion que le Web de documents qui se reliaient entre eux et qui étaient ailleurs devait être une chose évolutive et évolutive, donc il était logique qu'une suite de méthodes existe, pour permettre aux utilisateurs autorisés convenablement qualifiés de mettre à jour le Web sans nécessairement avoir accès au système de fichiers du serveur - indiquez le cas d'utilisation pour les options PUT et DELETE, et d'autres méthodes comme HEAD n'a renvoyé que des métadonnées sur un document afin que le client puisse décider de l'obtenir encore une fois (rappelez-vous que nous parlons de l'époque des modems commutés, technologie lente vraiment primitive. Cela pourrait être une grande économie d'obtenir la méta d'un fichier d'un demi-mégaoctet et de voir qu'il n'avait pas changé et de serveur plutôt la copie locale du cache que télécharger à nouveau
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 commuter 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 du dossier 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 Wikipédia - mais il suffit de dire qu'au fil du 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 plugins et extensions de navigateur, tous destinés à faire du navigateur une centrale de tout pouvoir. 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 de personnes et remplissaient des salles, il était courant de permettre à plusieurs utilisateurs d'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 quelque peu à un serveur central fournissant la plupart des fonctionnalités utiles de l'application et une centaine d'ordinateurs clients qui font très peu sauf dessiner sur l'écran, et soumettre et recevoir des données à/du 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é générées principalement de manière dynamique 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 branler leur mise en page, donc ça a été 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 seule page d'application; 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 que le navigateur ne charge 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 faire dessiner votre interface utilisateur est de lui fournir du html/css qui fait une interface utilisateur, puis ajustez le html en permanence 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?
C'est en effet un GET. 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 simplement 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 au-dessus desquels 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 intègre toutes ses informations variables dans l'url et qui a une limite de longueur dans de nombreux serveurs. Le client veut une longue réponse du serveur - n'utilisez pas de HEAD car ils ne sont pas censés avoir de corps de réponse Peut-être que le navigateur et le serveur que vous avez choisis n'ont aucune restriction, mais peut-être qu'un jour, ils rencontreront chacun une implémentation différente à l'autre extrémité - et dans un esprit d'interopérabilité, s'en tenir à une spécification le fera fonctionner mieux
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 ne correspondait pas tout à fait aux applications qui ont suivi, et les applications ont implémenté leur propre modèle avec seulement GET et POST - mais HTTP ne pouvait pas être jeté d'ici là.
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 respecté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 ont utilisé 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 , donc 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é les vieux jours où les serveurs HTTP étaient là juste pour servir fichiers; ne pas exécuter de script, CGI ou créer un contenu dynamique de ce type.
Les méthodes de demande sont basiques standardisé ensemble de verbes sur que faire avec ces fichiers ...
- GET signifie téléchargez
- HEAD signifie obtenez des informations sur
- PUT signifie upload
- EFFACER signifie supprimer
- POST signifie envoyer des données dans
- OPTIONS signifie dites-moi ce que je pourrais faire
Au jour de HTTP/0.9, la ligne de requête est le seule chose dans la jambe de requête du protocole; aucun en-tête de demande, aucun en-tête de réponse. Vous venez de taper GET /somefile, presse 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é initialement écrit 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 ces sémantiques dans le 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 devriez pas implémentez la logique d'application d'une manière qui défie attentes du protocole: les attentes comme GET ne devraient pas modifier les données (ou très lâchement, avoir au moins idempotent résultat), 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 bien réfléchir à ses implications, diverses choses désagréables se produiraient, comme ...
- Lorsque vous utilisez la méthode GET dans l'utilisation de la soumission de données, le serveur peut cracher une erreur de 414 " URI trop longue" sur votre visage.
- 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 que 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) caution sur votre site. - Lorsque vous chausse-pied 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 des 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 discrimination à vos utilisateurs.
Il est vrai en théorie que 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 lesquels sont lesquels
C'est important par exemple lors de l'interaction avec d'autres applications. Les points de terminaison 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 case de confirmation moche si vous appuyez sur f5 sur une demande de publication.
Voyez ce que 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 requête), mais renvoie quelque chose.
POST_MyVar(string blah) fait quelque chose avec l'entrée (encore une fois, le corps de la requête) 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, il faudrait écrire if (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, GET est pour les téléchargements et POST est pour 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 d'implémenter POST. GET n'a pas de corps 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. POST a à 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 implémenter POST et terminer? 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. Les demandes POST ne sont généralement envoyées que lorsque des formulaires dans des pages Web sont soumis ou pour des appels AJAX. Ce n'est que si ce serveur particulier n'est utilisé que pour les appels AJAX, et non pour les pages visibles par les utilisateurs, que vous pourrez vous en sortir avec POST uniquement.
Les navigateurs envoient également parfois HEAD des demandes 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 l'implémenter au moins également.
Dans tous les cas, il n'y a pas de bonne raison d'implémenter un serveur Web pour votre site à 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 au-dessus d'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 POST et rien d'autre, bien que je doive concéder l'élimination de GET serait une entreprise énorme, cela ne pouvait pas être fait, le cheval a déjà boulonné sur celui-là