Quelle est la différence entre une requête POST et une requête HTTP PUT?

Question

Ils semblent tous deux envoyer des données au serveur à l'intérieur du corps, alors qu'est-ce qui les rend différents?

Answer 1

PUT HTTP:

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 cachées. .

Emplacement RFC HTTP 1.1 pour PUT

POST HTTP:

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 , mais les réponses POST < em> sont en mémoire cache tant que le serveur définit les en-têtes Cache-Control et Expires appropriés.

La RFC HTTP officielle spécifie que le POST est:

• Annotation des ressources existantes;
• Publier un message sur un babillard, un groupe de discussion, une liste de diffusion,    ou groupe d'articles similaire;
• Fournir un bloc de données, tel que le résultat de la soumission d'un     formulaire, à un processus de traitement de données;
• Extension d'une base de données via une opération d'ajout.

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 le   Les requêtes POST et PUT sont reflétées dans   le sens différent du   Request-URI. L'URI dans une requête POST   identifie la ressource qui   gérer l'entité incluse. Cette   ressource pourrait ê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 requête PUT identifie le   entité jointe à la demande -   l'agent utilisateur sait ce qu'est l'URI   prévu et le serveur NE DOIT PAS   tenter 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é ou non de rediriger la demande.

En utilisant la bonne méthode, sans lien de parenté:

Un des avantages de REST ROA par rapport à SOAP est que, lorsque vous utilisez HTTP REST ROA, il encourage utilisation correcte des verbes / méthodes 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.

Answer 2

Seulement la sémantique.

Un PUT HTTP est supposé accepter le corps de la demande, puis le stocker dans la ressource identifiée par l'URI.

Un POST HTTP est plus général. Il est supposé initier une action sur le serveur. Cette action peut consister à stocker le corps de la demande au niveau de la ressource identifiée par l’URI, ou bien il peut s’agir d’une adresse URI différente ou d’une action différente.

PUT est semblable à un téléchargement de fichier. Un put à un URI affecte exactement cet URI. Un envoi postal à un URI pourrait avoir un effet quelconque.

Answer 3

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" soit créer un nouveau livre avec l’identifiant de 5, soit remplacer le livre existant avec l’ID 5.

Dans un style sans ressource, le 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 de la même donnée vers la même URL devraient suffire, alors que plusieurs POST pourraient créer plusieurs objets ou quoi que ce soit que votre action POST fasse.

Answer 4

PUT est conçu comme une méthode de "téléchargement". trucs à un URI particulier, ou écraser ce qui est déjà dans cet URI.

POST, en revanche, est un moyen de soumettre des données RELATIVES à un URI donné.

Voir HTTP RFC

Answer 5

Autant que je sache, PUT est principalement utilisé pour mettre à jour les enregistrements.

1. POST - Pour créer un document ou toute autre ressource

2. 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.

Answer 6

D'autres ont déjà publié 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 souvent affaire à POST que PUT. Au point où PUT, DELETE, etc. sont des questions triviales.

Answer 7

1. GET : récupère les données du serveur. Ne devrait avoir aucun autre effet.
2. POST : envoie des données au serveur en vue de la création d'une nouvelle entité. Souvent utilisé lors du téléchargement d'un fichier ou de l'envoi d'un formulaire Web.
3. PUT : Similaire à POST, mais utilisé pour remplacer une entité existante.
4. PATCH : similaire à PUT, mais utilisé pour mettre à jour uniquement certains champs d'une entité existante.
5. SUPPRIMER : supprime les données du serveur.
6. TRACE : permet de tester le type de réception du serveur. Il retourne simplement ce qui a été envoyé.
7. 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.
8. HEAD : renvoie uniquement les en-têtes de réponse.
9. 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, de sorte que les données ne soient pas lisibles par un proxy.

Answer 8

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 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 à un POST qui créera quelque chose et renverra une URL à le cas échéant).

Answer 9

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 / modifier une nouvelle me gêne assez.

Si vous consultez la page 55 de la RFC 2616 («Protocole de transfert d'hypertexte - 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.

Un paragraphe pratique explique également 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 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 ceci:

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.

Answer 10

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 de base REST établit une correspondance individuelle entre créer, lire, mettre à jour et supprimer (CRUD) des opérations et des méthodes HTTP. Selon ce cartographie:

& # 8226; Pour créer une ressource sur le serveur, utilisez POST.

& # 8226; Pour récupérer une ressource, utilisez GET.

& # 8226; Pour changer l'état d'une ressource ou la mettre à jour, utilisez PUT.

& # 8226; Pour supprimer ou supprimer une ressource, utilisez DELETE.

Plus d'infos: Services Web RESTful: notions de base d'IBM

Answer 11

La différence entre POST et PUT réside dans le fait que PUT est idempotent. Autrement dit, l'appel répété de la même demande PUT produira toujours le même résultat (sans effet secondaire), tandis que l'appel d'une requête POST à ??répétition 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 des 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 d'accès à la ressource cible, fournissant ainsi 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 désigner l'ensemble du serveur.

HEAD : Il 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 aux sites Web utilisant SSL (HTTPS)

Answer 12

Il convient de mentionner que POST est sujet à certaines attaques CSRF alors que PUT ne l'est pas.

Les CSRF ci-dessous sont impossibles 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"]);

Answer 13

Simplement

POST est utilisé pour créer une ressource et renvoie la ressource URI . EX

REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}

Cet appel doit créer un nouveau livre et renvoyer ce livre URI

.

Response ..../books/5

PUT est utilisé pour remplacer une ressource. Si cette ressource existe, mettez-la simplement à 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'identifiant de la ressource, mais POST renverra le nouvel identifiant de la ressource