Réponses:
HTTP PUT:
PUT place un fichier ou une ressource à un URI spécifique, et exactement à 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 RFC HTTP 1.1 pour PUT
POST HTTP:
POST envoie des données à un URI spécifique et attend que la ressource à cet URI gère la demande. À ce stade, le serveur Web 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 idempotente , mais les réponses POST peuvent être mises en cache tant que le serveur définit les en-têtes Cache-Control et Expires appropriés.
Le RFC HTTP officiel spécifie que POST doit être:
Emplacement 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 les requêtes POST et PUT se reflète 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 d'acceptation de données, une passerelle vers un autre protocole ou une entité distincte qui accepte les annotations. En revanche, l'URI dans une demande PUT identifie l'entité jointe à la demande - l'agent utilisateur sait quel URI est prévu et le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource. Si le serveur souhaite que la demande soit appliquée à un URI différent, il DOIT envoyer une réponse 301 (déplacée en permanence); l'agent utilisateur PEUT alors prendre sa propre décision concernant la redirection ou non de la demande.
De plus, et de façon un peu plus concise, la RFC 7231 Section 4.3.4 PUT déclare (non souligné dans l'original),
4.3.4. METTRE
La méthode PUT demande que l'état de la ressource cible soit
createdoureplacedavec l'état défini par la représentation incluse dans la charge utile du message de demande.
En utilisant la bonne méthode, sans lien de parenté:
Un avantage de REST ROA vs SOAP est que lors de l'utilisation de HTTP REST ROA, il encourage l'utilisation correcte des verbes / méthodes HTTP. Ainsi, par exemple, vous n'utiliseriez PUT que lorsque vous souhaitez créer une ressource à cet emplacement exact. Et vous n'utiliseriez jamais GET pour créer ou modifier une ressource.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Donc, une implémentation de PUT qui refuse de créer une ressource si elle n'est pas présente serait correcte, non? Si oui, cela se produit-il dans la pratique? Ou les implémentations créent-elles généralement sur PUT?
Seule la sémantique.
Un HTTP PUTest censé accepter le corps de la demande, puis le stocker sur la ressource identifiée par l'URI.
Un HTTP POSTest plus général. Il est censé lancer une action sur le serveur. Cette action peut consister à stocker le corps de la demande sur la ressource identifiée par l'URI, ou il peut s'agir d'un URI différent ou d'une action différente.
PUT est comme un téléchargement de fichier. Un put à un URI affecte exactement cet URI. Un POST sur un URI pourrait avoir n'importe quel effet.
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" devrait soit créer un nouveau livre avec l'ID de 5, soit remplacer le livre existant par l'ID 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 le PUT doit être idempotent - plusieurs PUT des mêmes données vers la même URL devraient être corrects, alors que plusieurs POST peuvent créer plusieurs objets ou quoi que ce soit votre action POST.
PUT est conçu comme une méthode pour "télécharger" des éléments vers un URI particulier, ou pour remplacer ce qui est déjà dans cet URI.
POST, d'autre part, est un moyen de soumettre des données liées à un URI donné.
Référez-vous au 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, il «remplace» généralement l'enregistrement existant s'il existe et crée s'il n'y est pas.
D'autres ont déjà posté d'excellentes réponses, je voulais juste ajouter qu'avec la plupart des langages, des frameworks et des cas d'utilisation, vous aurez beaucoup plus à faire avec POST qu'avec PUT. Au point où PUT, DELETE, etc. sont essentiellement des questions triviales.
Veuillez consulter: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
J'ai été assez ennuyé récemment par une idée fausse très répandue des développeurs Web selon laquelle un POST est utilisé pour créer une ressource, et un PUT est utilisé pour en mettre à jour / en modifier une.
Si vous jetez un œil à la page 55 de la RFC 2616 («Hypertext Transfer Protocol - HTTP / 1.1»), Section 9.6 («PUT»), vous verrez à quoi sert réellement PUT:
La méthode PUT demande que l'entité incluse soit stockée sous l'URI de demande fourni.
Il y a aussi un paragraphe pratique pour expliquer la différence entre POST et PUT:
La différence fondamentale entre les requêtes POST et PUT se reflète 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 d'acceptation de données, une passerelle vers un autre protocole ou une entité distincte qui accepte les annotations. En revanche, l'URI dans une demande PUT identifie l'entité jointe à la demande - l'agent utilisateur sait quel URI est prévu et le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource.
Il ne mentionne rien sur la différence entre la mise à jour / création, car ce n'est pas de cela qu'il s'agit. Il s'agit de la différence entre cela:
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.
Un 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 à une URL donnée, ou pour créer quelque chose de nouveau lorsque vous savez ce que l'URI va être et qu'il n'existe pas déjà (par opposition à un POST qui créera quelque chose et renverra une URL à si nécessaire).
REST demande aux développeurs d'utiliser les méthodes HTTP de manière explicite et d'une manière cohérente avec la définition du protocole. Ce principe de conception REST de base établit un mappage un à un entre les opérations de création, de lecture, de mise à jour et de suppression (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 modifier l'état d'une ressource ou pour la mettre à jour, utilisez PUT.
• Pour supprimer ou supprimer une ressource, utilisez DELETE.
Plus d'informations: Services Web RESTful: les bases d'IBM
Il devrait être assez simple d'utiliser l'un ou l'autre, mais des formulations complexes sont une source de confusion pour beaucoup d'entre nous.
À utiliser PUTlorsque vous souhaitez modifier une ressource singulière qui fait déjà partie de la collection de ressources. PUTremplace la ressource dans son intégralité. Exemple:PUT /resources/:resourceId
Sidenote: à utiliser PATCHsi vous souhaitez mettre à jour une partie de la ressource.
POSTlorsque vous souhaitez ajouter une ressource enfant sous une collection de ressources. POST => /resourcesPUTpour les opérations UPDATE .POSTpour les opérations CREATE .GET / company / reports => Obtenir tous les rapports
GET / company / reports / {id} => Obtenir les informations de rapport identifiées par "id"
POST / company / reports => Créer un nouveau rapport
PUT / company / reports / {id} => Mettre à jour le signaler les informations identifiées par "id"
PATCH / société / rapports / {id} => Mettre à jour une partie des informations de rapport identifiées par "id"
DELETE / entreprise / rapports / {id} => Supprimer le rapport par "id"
La différence entre POST et PUT est que PUT est idempotent, ce qui signifie que l'appel de la même demande PUT plusieurs fois produira toujours le même résultat (ce qui n'est pas un effet secondaire), tandis que d'un autre côté, l'appel répété d'une demande POST peut avoir ( effets secondaires supplémentaires) de la création de la même ressource plusieurs fois.
GET : Les requêtes utilisant GET récupèrent uniquement 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 utile de la demande
PATCH : Il est utilisé pour appliquer des modifications partielles à une ressource
DELETE : Il supprime la ressource spécifiée
TRACE : Il effectue un test de bouclage de message le long du chemin vers la ressource cible, fournissant un mécanisme de débogage utile
OPTIONS : Il est utilisé pour décrire les options de communication pour la ressource cible, le client peut spécifier une URL pour la méthode OPTIONS, ou un astérisque (*) pour faire référence à l'ensemble du serveur.
HEAD : Il demande une réponse identique à celle d'une requête GET, mais sans le corps de réponse
CONNECT : Il établit un tunnel vers le serveur identifié par la ressource cible, peut être utilisé pour accéder aux sites Web qui utilisent SSL (HTTPS)
Utilisation REST-ful
POST est utilisé pour créer une nouvelle ressource, puis retourne la ressource URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Cet appel peut créer un nouveau livre et retourner ce livre URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT est utilisé pour remplacer une ressource, si cette ressource existe, alors mettez-la simplement à jour, mais si cette ressource n'existe pas, créez-la,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
Avec PUTnous connaissons l'identifiant de ressource, mais POSTretournerons le nouvel identifiant de ressource
Utilisation non conforme à REST
POST est utilisé pour initier une action côté serveur, cette action peut ou non créer une ressource, mais cette action aura des effets secondaires toujours elle changera quelque chose sur le serveur
PUT est utilisé pour placer ou remplacer le contenu littéral à une URL spécifique
Une autre différence dans les styles REST-ful et non REST-ful
POST est une opération non idempotente: elle entraînera des modifications si elle est exécutée plusieurs fois avec la même demande.
PUT est une opération idempotente: elle n'aura aucun effet secondaire si elle est exécutée plusieurs fois avec la même demande.
Il convient de mentionner qu'il POSTest soumis à certaines attaques communes de contrefaçon de demande intersite (CSRF) alors qu'il PUTne l'est pas.
Les CSRF ci-dessous nePUT sont pas possibles avec la visite de la victime attackersite.com.
L' effet de l'attaque est que la victime supprime accidentellement un utilisateur juste parce qu'il (la victime) était aussi connecté adminsur target.site.com, avant de visiter attackersite.com:
Demande normale (des cookies sont envoyés): ( PUTn'est pas une valeur d'attribut prise en charge)
Code sur attackersite.com:
<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 (des cookies sont envoyés): ( PUTdéclencherait une demande de contrôle en amont, dont la réponse empêcherait le navigateur de demander la deleteUserpage)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
En termes simples, vous pouvez dire:
1.HTTP Get: Il est utilisé pour obtenir un ou plusieurs éléments
2.HTTP Post: Il est utilisé pour créer un élément
3.HTTP Put: il est utilisé pour mettre à jour un élément
4.HTTP Patch: il est utilisé pour mettre à jour partiellement un élément
5.HTTP Delete: permet de supprimer un élément
En fait, il n'y a pas de différence autre que leur titre. Il y a en fait une différence fondamentale entre GET et les autres. Avec une méthode "GET" -Request, vous envoyez les données dans la ligne d'adresse URL, qui sont d'abord séparées par un point d'interrogation, puis avec un signe &.
Mais avec une méthode de demande "POST", vous ne pouvez pas passer de données via l'URL, mais vous devez passer les données en tant qu'objet dans le soi-disant "corps" de la demande. Côté serveur, vous devez ensuite lire le corps du contenu reçu afin d'obtenir les données envoyées. Mais il n'y a pas d'autre possibilité d'envoyer du contenu dans le corps, lorsque vous envoyez une requête "GET".
L'affirmation selon laquelle "GET" est uniquement pour obtenir des données et "POST" pour publier des données, est absolument erronée. Personne ne peut vous empêcher de créer un nouveau contenu, de supprimer un contenu existant, de modifier un contenu existant ou de faire quoi que ce soit dans le backend, sur la base des données, qui est envoyé par la demande "GET" ou par la demande "POST". Et personne ne peut vous empêcher de coder le backend d'une manière qui, avec une requête "POST", le client demande des données.
Avec une demande, quelle que soit la méthode que vous utilisez, vous appelez une URL et envoyez ou n'envoyez pas de données à spécifier, quelles informations vous souhaitez transmettre au serveur pour traiter votre demande, puis le client obtient une réponse de le serveur. Les données peuvent contenir tout ce que vous voulez envoyer, le backend est autorisé à faire ce qu'il veut avec les données et la réponse peut contenir toutes les informations que vous souhaitez y mettre.
Il n'y a que ces deux MÉTHODES DE BASE. GET et POST. Mais c'est leur structure, qui les rend différents et non ce que vous codez dans le backend. Dans le backend, vous pouvez coder ce que vous voulez, avec les données reçues. Mais avec la demande "POST", vous devez envoyer / récupérer les données dans le corps et non dans la ligne d'adresse URL, et avec une demande "GET", vous devez envoyer / récupérer les données dans la ligne d'adresse URL et non dans le corps. C'est tout.
Toutes les autres méthodes, comme "PUT", "DELETE" et ainsi de suite, ont la même structure que "POST".
La méthode POST est principalement utilisée, si vous souhaitez masquer un peu le contenu, car quoi que vous écriviez dans la ligne d'adresse URL, cela sera enregistré dans le cache et une méthode GET revient à écrire une ligne d'adresse URL avec des données. Donc, si vous souhaitez envoyer des données sensibles, qui ne sont pas toujours nécessairement un nom d'utilisateur et un mot de passe, mais par exemple des identifiants ou des hachages, que vous ne souhaitez pas voir apparaître dans la ligne d'adresse URL, vous devez utiliser la méthode POST .
De plus, la longueur de la ligne d'adresse URL est limitée à 1024 symboles, tandis que la méthode "POST" n'est pas restreinte. Donc, si vous avez une plus grande quantité de données, vous ne pourrez peut-être pas l'envoyer avec une demande GET, mais vous devrez utiliser la demande POST. C'est donc aussi un autre point positif pour la requête POST.
Mais traiter la demande GET est beaucoup plus facile lorsque vous n'avez pas de texte compliqué à envoyer. Sinon, et c'est un autre point positif pour la méthode POST, c'est qu'avec la méthode GET, vous devez encoder le texte par URL, afin de pouvoir envoyer des symboles dans le texte ou même des espaces. Mais avec une méthode POST, vous n'avez aucune restriction et votre contenu n'a pas besoin d'être modifié ou manipulé de quelque manière que ce soit.
PUT et POST sont des méthodes de repos.
PUT - Si nous faisons la même demande deux fois en utilisant PUT en utilisant les mêmes paramètres les deux fois, la deuxième demande n'aura aucun effet. C'est pourquoi PUT est généralement utilisé pour le scénario Update, appeler Update plusieurs fois avec les mêmes paramètres ne fait rien de plus que l'appel initial, donc PUT est idempotent.
POST n'est pas idempotent, par exemple, Create créera deux entrées distinctes dans la cible donc il n'est pas idempotent donc CREATE est largement utilisé dans POST.
Faire le même appel à l'aide de POST avec les mêmes paramètres à chaque fois entraînera deux choses différentes, d'où pourquoi POST est couramment utilisé pour le scénario de création