Quelle est la différence entre un POST et une demande HTTP PUT?
Ils semblent tous deux envoyer des données au serveur à l'intérieur du corps, alors qu'est-ce qui les rend différents?
HTTP PUT:
PUT place un fichier ou une ressource sur un URI spécifique et exactement sur cet URI. S'il existe déjà un fichier ou une ressource à cet URI, PUT remplace ce fichier ou cette ressource. S'il n'y a ni fichier ni ressource, PUT en crée un. PUT est idempotent , mais paradoxalement les réponses PUT ne peuvent pas être mises en cache.
Emplacement HTTP 1.1 RFC pour PUT
HTTP POST:
Le POST envoie des données à un URI spécifique et attend de la ressource de cet URI qu'elle gère la demande. Le serveur Web à ce stade peut déterminer quoi faire avec les données dans le contexte de la ressource spécifiée. La méthode POST n'est pas idempotent , cependant POST réponses sont pouvant être mis en cache tant que le serveur définit les en-têtes Cache-Control et Expires appropriés.
La RFC HTTP officielle spécifie que POST est:
- Annotation des ressources existantes;
- Publier un message sur un babillard, un groupe de discussion, une liste de diffusion, ou groupe d'articles similaires;
- Fournir un bloc de données, tel que le résultat de la soumission d'un forme, à un processus de traitement de données;
- Extension d'une base de données via une opération d'ajout.
Emplacement du RFC HTTP 1.1 pour POST
Différence entre POST et PUT:
Le RFC lui-même explique la différence fondamentale:
La différence fondamentale entre le POST et les requêtes PUT sont reflétés dans le sens différent du Request-URI. L'URI dans une demande POST identifie la ressource qui va gérer l'entité incluse. Cette ressource peut être un. acceptant les données. processus, une passerelle vers un autre protocole, ou une entité séparée qui accepte les annotations. En revanche, le L'URI dans une demande PUT identifie le entité jointe à la demande -- l'agent utilisateur sait ce qu'est l'URI prévu et le serveur NE DOIT PAS essayer d'appliquer la demande à certains autre ressource. Si le serveur le souhaite que la demande soit appliquée à un adresse URI différente, il DOIT envoyer une réponse 301 (déplacé de façon permanente); l'agent utilisateur PEUT alors faire sa propre décision quant à l'opportunité de rediriger ou non la demande.
En utilisant la bonne méthode, sans lien de côté:
Un des avantages de REST ROA vs SOAP est que l'utilisation de HTTP REST ROA encourage l'utilisation correcte des méthodes/verbes HTTP. Ainsi, par exemple, vous n’utiliseriez PUT que lorsque vous souhaitez créer une ressource à cet emplacement précis. Et vous n’utiliseriez jamais GET pour créer ou modifier une ressource.
Seulement la sémantique.
Une HTTP PUT est supposée accepter le corps de la demande, puis la stocker dans la ressource identifiée par l'URI.
Un HTTP POST est plus général. Il est supposé initier une action sur le serveur. Cette action peut consister à stocker le corps de la demande sur la ressource identifiée par l'URI, ou peut-être une autre adresse, ou une action différente.
PUT est comme un fichier téléchargé. Un put à un URI affecte exactement cet URI. Un POST à un URI pourrait avoir un effet quelconque.
Pour donner des exemples de ressources de style REST:
"POST/books" avec un tas d'informations sur le livre peut créer un nouveau livre et répondre avec la nouvelle URL identifiant ce livre: "/ books/5".
"PUT/books/5" devra soit créer un nouveau livre avec l'identifiant 5, soit remplacer le livre existant par l'identifiant 5.
Dans un style sans ressource, POST peut être utilisé pour à peu près tout ce qui a un effet secondaire. Une autre différence est que PUT devrait être idempotent - plusieurs PUT des mêmes données vers la même URL devraient suffire, plusieurs POST pouvant créer plusieurs objets ou quoi que ce soit de votre action POST.
PUT est conçu comme une méthode permettant de "télécharger" des éléments dans un URI particulier ou de remplacer ce qui se trouve déjà dans cet URI.
POST, en revanche, est un moyen de soumettre des données en rapport avec un URI donné.
Reportez-vous à le HTTP RFC
Autant que je sache, PUT est principalement utilisé pour mettre à jour les enregistrements.
POST - Pour créer un document ou toute autre ressource
PUT - Pour mettre à jour le document créé ou toute autre ressource.
Mais pour être clair sur ce PUT, généralement "remplace" l'enregistrement existant s'il est là et crée s'il ne l'est pas.
D'autres ont déjà publié d'excellentes réponses. Je voulais juste ajouter qu'avec la plupart des langues, des frameworks et des cas d'utilisation que vous allez traiter POST beaucoup plus souvent que PUT. Au point où PUT, DELETE, etc. sont fondamentalement des questions triviales.
- GET: Récupère les données du serveur. Ne devrait avoir aucun autre effet.
- POST: Envoie des données au serveur pour créer une nouvelle entité. Souvent utilisé lors du téléchargement d'un fichier ou de la soumission d'un formulaire Web.
- PUT: Similaire à POST, mais utilisé pour remplacer une entité existante.
- PATCH: Similaire à PUT, mais utilisé pour mettre à jour uniquement certains champs d'une entité existante.
- DELETE: Supprime les données du serveur.
- TRACE: Fournit un moyen de tester ce que le serveur reçoit. Il retourne simplement ce qui a été envoyé.
- OPTIONS: Permet à un client d'obtenir des informations sur les méthodes de requête prises en charge par un service. L'en-tête de réponse approprié est Autoriser avec les méthodes prises en charge. Également utilisé dans CORS en tant que demande de contrôle en amont pour informer le serveur de la méthode de demande réelle et demander des en-têtes personnalisés.
- HEAD: Renvoie uniquement les en-têtes de réponse.
- CONNECT: Utilisé par le navigateur lorsqu'il sait qu'il communique avec un proxy et que l'URI final commence par https: //. L'objectif de CONNECT est d'autoriser une session TLS cryptée de bout en bout, afin que les données soient illisibles pour un proxy.
A POST est considéré comme une méthode de type usine. Vous incluez des données avec pour créer ce que vous voulez et tout ce qui se trouve à l’autre bout sait quoi en faire. Un PUT est utilisé pour mettre à jour des données existantes sur une URL donnée ou pour créer quelque chose de nouveau lorsque vous savez ce que sera l'URI et qu'il n'existe pas déjà (par opposition à POST quelque chose et renvoyer une URL si nécessaire).
Veuillez consulter: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
L’idée fausse répandue récemment par les développeurs Web selon laquelle un POST est utilisé pour créer une ressource et un PUT est utilisé pour en mettre à jour/changer les choses me gêne un peu.
Si vous consultez la page 55 de la RFC 2616 («Protocole de transfert hypertexte - HTTP/1.1»), Section 9.6 («PUT»), vous verrez à quoi sert réellement PUT:
La méthode PUT demande à ce que l'entité incluse soit stockée sous l'URI de demande fourni.
Il existe également un paragraphe pratique expliquant la différence entre POST et PUT:
La différence fondamentale entre les requêtes POST et PUT est reflétée dans la signification différente de l'URI de demande. L'URI dans une demande POST identifie la ressource qui gérera l'entité incluse. Cette ressource peut être un processus acceptant les données, une passerelle vers un autre protocole ou une entité distincte acceptant les annotations. En revanche, l'URI dans une demande PUT identifie l'entité jointe à la demande - l'agent d'utilisateur sait ce que l'URI est destiné et le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource.
Il ne fait aucune mention de la différence entre la mise à jour et la création, car ce n’est pas sa raison d’être. Il s’agit de la différence entre ceci:
obj.set_attribute(value) # A POST request.
Et ça:
obj.attribute = value # A PUT request.
Alors s'il vous plaît, arrêtez la propagation de cette idée fausse populaire. Lisez vos RFC.
REST demande aux développeurs d'utiliser les méthodes HTTP de manière explicite et cohérente avec la définition du protocole Ce principe de conception REST de base établit un mappage univoque entre les opérations Create, read, update et delete (CRUD) et les méthodes HTTP. Selon cette cartographie
• Pour créer une ressource sur le serveur, utilisez POST.
• Pour récupérer une ressource, utilisez GET.
• Pour changer l'état d'une ressource ou la mettre à jour, utilisez PUT.
• Pour supprimer ou supprimer une ressource, utilisez DELETE.
Plus d'infos: Services Web RESTful: notions de base d’IBM
Il vaut la peine de mentionner que POST est soumis à quelques attaques de CSRFcommunes tandis que PUT ne l’est pas.
Les CSRF ci-dessous sont impossible avec PUT lorsque la victime se rend sur le site attaquante.com:
Demande normale (les cookies sont envoyés): (PUT n'est pas une valeur d'attribut prise en charge)
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
Demande XHR (les cookies sont envoyés): (PUT déclencherait une demande de contrôle en amont)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
Simplement
POST est utilisé pour créer une ressource et renvoie la ressource URI EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Cet appel devrait créer un nouveau livre et le renvoyer URI
Response ..../books/5
PUT est utilisé pour remplacer une ressource. Si cette ressource existe, il suffit de la mettre à jour, mais si cette ressource n'existe pas, créez-la,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
en utilisant PUT, nous fournirons l'identificateur de ressource, mais POST renverra le nouvel identificateur de ressource
La différence entre POST et PUT est que PUT est idempotent. Autrement dit, appeler plusieurs fois la même demande PUT produira toujours le même résultat (sans effet secondaire), tandis que l'appel d'un POST répétée peut avoir des effets secondaires (supplémentaires) de créer la même ressource plusieurs fois.
GET: les requêtes utilisant GET ne récupèrent que les données, c’est-à-dire qu’elles demandent une représentation de la ressource spécifiée
POST: Il envoie des données au serveur pour créer une ressource. Le type du corps de la demande est indiqué par l'en-tête Content-Type. Cela provoque souvent un changement d'état ou des effets secondaires sur le serveur
PUT: crée une nouvelle ressource ou remplace une représentation de la ressource cible par la charge de la requête
PATCH: Il est utilisé pour appliquer des modifications partielles à une ressource.
DELETE: supprime la ressource spécifiée
TRACE: Il effectue un test de bouclage de message le long du chemin d'accès à la ressource cible, fournissant un mécanisme de débogage utile.
OPTIONS: Il est utilisé pour décrire les options de communication de la ressource cible. Le client peut spécifier une URL pour la méthode OPTIONS ou un astérisque (*) pour faire référence au serveur entier.
HEAD: demande une réponse identique à celle d'une requête GET, mais sans le corps de la réponse
CONNECT: Il établit un tunnel vers le serveur identifié par la ressource cible, peut être utilisé pour accéder à des sites Web utilisant SSL (HTTPS).