Quelle est la différence entre une 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 différencie?

    HTTP PUT:

    PUT met 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 aucun fichier ou 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:

    POST envoie des données à un URI spécifique et attend que la ressource de cet URI 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 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:

    • Annotation des ressources existantes;
    • Publier un message sur un tableau d’affichage, un groupe de discussion, une liste de diffusion ou un 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 des données;
    • Extension d’une firebase database via une opération d’ajout.

    Emplacement HTTP 1.1 RFC pour POST

    Différence entre POST et PUT:

    La RFC elle-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 requête 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 à quoi l’URI est destiné et le serveur NE DOIT PAS tenter d’appliquer la demande à une autre ressource. Si le serveur souhaite que la requête soit appliquée à un URI différent, il DOIT envoyer une réponse 301 (Moved Permanently); l’agent utilisateur PEUT alors prendre sa propre décision quant à savoir s’il faut ou non redirect la demande.

    En utilisant la bonne méthode, sans aucun rapport de côté:

    Un des avantages de REST ROA vs SOAP est que, lorsqu’on utilise HTTP REST ROA, il encourage l’utilisation correcte des verbes / méthodes HTTP. Ainsi, par exemple, vous utiliseriez uniquement PUT pour créer une ressource à cet endroit précis. Et vous n’utiliseriez jamais GET pour créer ou modifier une ressource.

    Seule la sémantique.

    Un HTTP PUT est supposé accepter le corps de la requête, puis le stocker sur la ressource identifiée par l’URI.

    Un HTTP POST est plus général. Il est censé lancer une action sur le serveur. Cette action pourrait consister à stocker le corps de la requête au niveau de la ressource identifiée par l’URI, ou bien à utiliser un URI différent, ou une action différente.

    PUT est comme un téléchargement de fichier. Une mise à un URI affecte exactement cette 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” devrait soit créer un nouveau livre avec l’ID de 5, soit remplacer le livre existant par l’ID 5.

    Dans un style autre que celui des ressources, 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 des mêmes données sur la même URL devraient convenir, alors que plusieurs POST pourraient créer plusieurs objects ou ce que fait votre action POST.

    1) GET: – Utilisé lorsque le client demande une ressource sur le serveur Web.

    2) HEAD: – Utilisé lorsque le client demande des informations sur une ressource mais ne demande pas la ressource elle-même.

    3) POST: – Utilisé lorsque le client envoie des informations ou des données au serveur, par exemple en remplissant un formulaire en ligne (c.-à-d. Envoie une grande quantité de données complexes au serveur Web).

    4) PUT: – Utilisé lorsque le client envoie un document de remplacement ou télécharge un nouveau document sur le serveur Web sous l’URL de la demande.

    5) DELETE: – Utilisé lorsque le client tente de supprimer un document du serveur Web, identifié par l’URL de la demande.

    6) TRACE: – Utilisé lorsque le client demande aux serveurs mandataires ou intermédiaires disponibles de modifier la demande pour s’annoncer.

    7) OPTIONS: – Utilisé lorsque le client souhaite déterminer d’autres méthodes disponibles pour récupérer ou traiter un document sur le serveur Web.

    8) CONNECT: – Utilisé lorsque le client souhaite établir une connexion transparente avec un hôte distant, généralement pour faciliter la communication cryptée SSL (HTTPS) via un proxy HTTP.

    PUT est conçu comme une méthode pour “télécharger” des choses dans un URI particulier, ou pour remplacer ce qui existe déjà dans cette URI.

    Le POST, quant à lui, est un moyen de soumettre des données liées à un URI donné.

    Reportez-vous à la RFC HTTP

    Pour 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 existe et crée s’il n’y est pas ..

    Selon RFC , la différence entre PUT et POST se trouve dans l’URI de la demande. L’URI identifié par POST définit l’entité qui gérera la demande POST. L’URI dans la requête PUT inclut l’entité dans la requête. Ainsi, POST /v1/coffees/orders signifie créer une nouvelle ressource et renvoyer un identifiant pour décrire la ressource. En revanche, PUT /v1/coffees/orders/1234 signifie mettre à jour une ressource identifiée par ” 1234 ” si elle existe; sinon créer une nouvelle commande et utiliser les orders/1234 URI orders/1234 pour l’identifier.

    PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.

    D’autres ont déjà publié d’excellentes réponses, je voulais juste append qu’avec la plupart des langages, des frameworks et des cas d’utilisation, vous aurez beaucoup à faire avec le POST, beaucoup plus souvent qu’avec PUT. Au point où PUT, DELETE, etc. sont essentiellement des questions sortingviales.

    Un POST est considéré comme une méthode de type usine. Vous incluez des données avec lui pour créer ce que vous voulez et tout ce qui se trouve à l’autre 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 à une POST qui créera quelque chose et renverra une URL à si nécessaire).

    S’il vous plaît voir: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

    J’ai été très contrarié ces derniers temps par une idée reçue des développeurs Web selon laquelle un POST est utilisé pour créer une ressource, et un PUT est utilisé pour en mettre à jour / changer.

    Si vous regardez la page 55 de la RFC 2616 (“Hypertext Transfer Protocol – HTTP / 1.1”), Section 9.6 (“PUT”), vous verrez ce que PUT est en fait pour:

    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 requête 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 à quoi l’URI est destiné 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 / la création, car ce n’est pas ce dont il s’agit. C’est à propos de la différence entre ceci:

     obj.set_atsortingbute(value) # A POST request. 

    Et ça:

     obj.atsortingbute = 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 une correspondance univoque entre les opérations CRUD (create, read, update et delete) 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 le mettre à jour, utilisez PUT.

    • Pour supprimer ou supprimer une ressource, utilisez DELETE.

    Plus d’infos: Services Web RESTful: les bases d’IBM

    La différence entre PUT et POST est la suivante:

    Le client utilise PUT lorsqu’il est chargé de décider quel URI doit avoir la nouvelle ressource.

    Le client utilise POST lorsque le serveur est chargé de décider quel URI doit avoir la nouvelle ressource.

    1. GET: récupère les données du serveur. Ne devrait avoir aucun autre effet.
    2. 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.
    3. PUT: Similaire à POST, mais utilisé pour remplacer une entité existante.
    4. PATCH: Similaire à PUT, mais utilisé pour ne mettre à jour que certains champs d’une entité existante.
    5. DELETE: Supprime les données du serveur.
    6. TRACE: Fournit un moyen de tester ce que le serveur reçoit. Il renvoie simplement ce qui a été envoyé.
    7. OPTIONS: Permet à un client d’obtenir des informations sur les méthodes de requête sockets en charge par un service. L’en-tête de réponse approprié est Autoriser avec les méthodes sockets en charge. Également utilisé dans CORS en tant que demande de contrôle en amont pour informer le serveur sur la méthode de requête réelle et pour en savoir plus sur les 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: //. Le but de CONNECT est de permettre une session TLS chiffrée de bout en bout, de sorte que les données soient illisibles pour un proxy.