Pourquoi avons-nous besoin de plus que HTTP GET, PUT, POST?
https://stackoverflow.com/questions/147187
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Quel est l'avantage pratique d'utiliser HTTP GET, PUT, DELETE, POST, HEAD? Pourquoi ne pas se concentrer sur leurs avantages comportementaux (sécurité et idempotence), oublier leurs noms et utiliser GET, PUT ou POST en fonction du comportement souhaité?
Pourquoi ne devrions-nous pas utiliser seulement GET, PUT et POST (et abandonner HEAD, DELETE)?
La solution
L'approche [REST] [1] utilise POST, GET, PUT et DELETE pour implémenter les règles CRUD d'une ressource Web. C'est un moyen simple et ordonné d'exposer des objets à des requêtes sur le Web. Ce sont des services Web sans frais généraux.
Juste pour clarifier les différences sémantiques. Chaque opération est assez différente. Le but est d’avoir de belles méthodes HTTP qui ont un sens clair et distinct.
Le POST crée de nouveaux objets. L'URI n'a pas de clé; il accepte un corps de message qui définit l'objet. Insertion SQL. < Modifier Bien qu'il n'y ait aucune raison technique pour que POST n'ait pas de clé, les gens de REST suggèrent fortement que pour que POST ait un sens distinct en tant que CREATE, il ne devrait pas avoir de clé.]
GET récupère les objets existants. L’URI peut avoir une clé, selon que vous utilisiez un singleton GET ou une liste GET. Sélection SQL
PUT met à jour un objet existant. L'URI a une clé; Il accepte un corps de message qui met à jour un objet. Mise à jour SQL.
DELETE supprime un objet existant. L'URI a une clé. Suppression SQL.
Pouvez-vous mettre à jour un enregistrement avec POST au lieu de PUT? Non sans introduire une ambiguïté. Les verbes devraient avoir des effets non ambigus. De plus, les URI POST n’ont pas de clé, PUT doit en avoir une.
Quand je poste, je m'attends à un 201 CREATED. Si je ne comprends pas ça, quelque chose ne va pas. De même, quand je mets, je m'attends à 200 OK. Si je ne comprends pas cela, quelque chose ne va pas.
Je suppose que vous pourriez insister sur l’ambiguïté selon laquelle POST effectue soit le post-test, soit le put. L'URI doit être différent. le message associé pourrait également être différent. Généralement, les utilisateurs de REST tirent leur inspiration de SQL où INSERT et UPDATE sont des verbes différents.
Vous pouvez faire valoir que UPDATE doit insérer si l’enregistrement n’existe pas ou être mis à jour s’il existe. Cependant, il est plus simple si UPDATE signifie UPDATE et qu'un échec de mise à jour signifie que quelque chose ne va pas. Un recours secret à INSERT rend l'opération ambiguë.
Si vous ne construisez pas une interface RESTful, il est typique d'utiliser uniquement GET et POST pour récupérer et créer / mettre à jour. Il est courant d'avoir des différences d'URI ou des différences de contenu de message pour faire la distinction entre POST et PUT lorsqu'une personne clique sur Soumettre sur un formulaire. Cependant, cela n’est pas très clair car votre code doit déterminer si vous êtes dans le cas POST = create case ou POST = update case.
Autres conseils
POST n'a aucune garantie de sécurité ou idempotency . C’est l’une des raisons pour lesquelles PUT et SUPPRIMER : PUT et DELETE sont idempotents (c’est-à-dire que les requêtes identiques 1 + N ont le même résultat final qu’une seule requête).
PUT est utilisé pour définir l'état d'une ressource à un URI donné. Lorsque vous envoyez une demande POST à une ressource située à un URI particulier, cette ressource ne doit pas être remplacée par la contenu. Tout au plus, il devrait être ajouté à. C'est pourquoi POST n'est pas idempotent. Dans le cas de l'ajout de POSTS, chaque requête s'ajoute à la ressource (par exemple, publiez un message nouveau sur un forum de discussion à chaque fois).
SUPPRIMER est utilisé pour s'assurer qu'une ressource d'un URI donné est supprimée du serveur. POST ne doit normalement pas être utilisé pour la suppression, sauf dans le cas où soumet une demande de suppression. Là encore, l’URI de la ressource à laquelle POST doit s’appliquer dans ce cas ne doit pas être l’URI de la ressource que vous souhaitez supprimer. Toute ressource pour laquelle vous postez est une ressource qui accepte que les données postées s'ajoutent à elles-mêmes, soient ajoutées à une collection ou soient traitées d'une autre manière.
HEAD est utilisé si vous ne vous souciez que des en-têtes d'une requête GET et que vous ne voulez pas gaspiller de la bande passante sur le contenu réel. C’est bien d’avoir.
Pourquoi avons-nous besoin de plus que de POST? Cela permet aux données de circuler dans les deux sens, alors pourquoi GET serait-il nécessaire? La réponse est fondamentalement la même que pour votre question. En normalisant les attentes de base des différentes méthodes, d'autres processus peuvent mieux savoir quoi faire.
Par exemple, les mandataires de mise en cache qui interviennent peuvent avoir une meilleure chance d'agir correctement.
Pensez à HEAD par exemple. Si le serveur proxy sait ce que signifie HEAD, il peut alors traiter le résultat d'une précédente requête GET afin de fournir la réponse appropriée à une requête HEAD. Et il peut savoir que POST, PUT et DELETE ne doivent pas être mis en cache.
Personne n'a mis en ligne le type de réponse que je cherchais, je vais donc essayer de résumer les points moi-même.
" Services Web RESTful " chapitre 8 section " Surcharge POST " se lit comme suit: "Si vous souhaitez vous passer de PUT et DELETE, il est tout à fait RESTful d’exposer les opérations sécurisées sur les ressources via GET et toutes les autres opérations via POST surchargé. Cela viole mon architecture axée sur les ressources, mais respecte les règles moins restrictives de REST. "
En bref, remplacer PUT / DELETE par POST rend l’API plus difficile à lire et les appels PUT / DELETE ne sont plus idempotents .
En un mot:
idempotency
En quelques mots:
GET = safe + idempotent
PUT = idempotent
DELETE = idempotent
POST = ni sûr ni idempotent
"Idempotent" signifie simplement que vous pouvez le faire encore et encore et qu'il fera toujours exactement la même chose.
Vous pouvez réémettre une demande PUT (update) ou DELETE autant de fois que vous le souhaitez et le même effet aura lieu à chaque fois. Toutefois, l'effet souhaité modifiera une ressource de sorte qu'elle ne soit pas considérée comme "sûre".
Une requête POST doit créer une nouvelle ressource avec chaque requête, ce qui signifie que l’effet sera différent à chaque fois. Par conséquent, le POST n’est pas considéré comme sûr ou idempotent.
Des méthodes telles que GET et HEAD ne sont que des opérations de lecture et sont donc considérées comme "sûres" et idempotentes.
C’est en fait un concept très important car il fournit un moyen standard / cohérent d’interpréter les transactions HTTP; cela est particulièrement utile dans un contexte de sécurité.
Tous les hôtes ne prennent pas en charge PUT, DELETE.
J'ai posé cette question, dans un monde idéal, nous aurions tous les verbes mais ....:
HEAD est vraiment utile pour déterminer le réglage de l’horloge d’un serveur donné (précision à la seconde près ou délai d’aller-retour du réseau, selon la valeur la plus longue). C'est également pratique pour obtenir des citations de Slashdot sur Futurama:
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
Pour CURL , -I est l'option permettant d'effectuer une demande HEAD. . Pour obtenir la date et l'heure actuelles d'un serveur donné, il suffit de
curl -I $ serveur | grep ^ date
Limiter les ambiguïtés qui permettront une réutilisation meilleure / plus simple de nos simples apis REST.
Vous pouvez utiliser uniquement GET et POST, mais vous perdez alors une partie de la précision et de la clarté apportées par PUT et DELETE. Le POST est une opération générique qui peut avoir une signification quelconque. Le comportement de PUT et DELETE est très bien défini. Si vous pensez à une API de gestion de ressources, alors GET, PUT et DELETE couvrent probablement 80% à 90% des fonctionnalités requises. Si vous vous limitez aux opérations GET et POST, vous accédez à 40% à 60% de votre API en utilisant un POST mal spécifié.
Les applications Web utilisant GET et POST permettent aux utilisateurs de créer, afficher, modifier et supprimer leurs données, mais le font au-dessus des commandes HTTP initialement créées à ces fins. Une des idées à la base de REST est un retour à l’intention initiale de la conception du Web, selon laquelle il existe des opérations HTTP spécifiques pour chaque verbe CRUD.
La commande HEAD peut également être utilisée pour améliorer l'expérience utilisateur lors du téléchargement de fichiers (potentiellement volumineux). Vous appelez HEAD pour connaître l’ampleur de la réponse, puis appelez GET pour récupérer le contenu.
Voir le lien suivant pour un exemple illustratif. Il suggère également une façon d’utiliser la méthode http OPTIONS, qui n’a pas encore été abordée ici.
Certaines extensions http telles que WebDAV nécessitent des fonctionnalités supplémentaires.
La guerre du serveur Web des premiers jours en est probablement la cause.
Dans HTTP 1.0 écrit en 1996, seuls GET, HEAD et POST . Mais comme vous pouvez le voir dans Annexe D , les fournisseurs ont commencé à ajouter leur propres choses. Pour rester compatibles avec HTTP, ils ont donc été obligés de faire HTTP 1.1 en 1999 . .
Cependant, HTTP / 1.0 ne prend pas suffisamment en compte effets des proxies hiérarchiques, la mise en cache, la nécessité de connexions persistantes ou hôtes virtuels. De plus, la prolifération d'applications incomplètement implémentées se faisant appeler "HTTP / 1.0" a nécessité un changement de version de protocole afin de deux applications communicantes pour déterminer leurs véritables capacités.
Cette spécification définit le protocole appelé "HTTP / 1.1". Ce protocole inclut des exigences plus strictes que HTTP / 1.0 dans l'ordre pour assurer une mise en œuvre fiable de ses fonctionnalités.
GET, PUT, DELETE et POST sont des vestiges d’une époque où les étudiants de deuxième année pensaient qu’une page Web pourrait être réduite à quelques principes très hiérarchiques.
De nos jours, la plupart des pages Web sont des entités composites, qui contiennent tout ou partie de ces opérations primitives. Par exemple, une page peut contenir des formulaires permettant de visualiser ou de mettre à jour les informations client, pouvant éventuellement couvrir plusieurs tableaux.
J'utilise habituellement $ _REQUEST [] en php, peu importe la façon dont l'information est arrivée. Je choisirais d’utiliser des méthodes GET ou PUT basées sur l’efficacité, pas sur les paradigmes sous-jacents (multiples).
