Selon la spécification HTTP / 1.1:
La
POST
méthode est utilisée pour demander que le serveur d'origine accepte l'entité incluse dans la demande en tant que nouveau subordonné de la ressource identifiée par leRequest-URI
dans leRequest-Line
En d'autres termes, POST
est utilisé pour créer .
La
PUT
méthode demande que l'entité incluse soit stockée sous le fourniRequest-URI
. Si leRequest-URI
fait référence à une ressource déjà existante, l'entité incluse DEVRAIT être considérée comme une version modifiée de celle résidant sur le serveur d'origine. Si leRequest-URI
ne pointe pas vers une ressource existante et que cet URI peut être défini comme une nouvelle ressource par l'agent utilisateur demandeur, le serveur d'origine peut créer la ressource avec cet URI. "
Autrement dit, PUT
est utilisé pour créer ou remplacer .
Alors, lequel devrait être utilisé pour créer une ressource? Ou faut-il soutenir les deux?
Réponses:
Global:
PUT et POST peuvent être utilisés pour la création.
Vous devez demander "à quoi effectuez-vous l'action?" pour distinguer ce que vous devez utiliser. Supposons que vous concevez une API pour poser des questions. Si vous souhaitez utiliser POST, vous le feriez pour une liste de questions. Si vous souhaitez utiliser PUT, vous le feriez pour une question particulière.
Les deux peuvent être utilisés, alors lequel dois-je utiliser dans ma conception RESTful:
Vous n'avez pas besoin de prendre en charge PUT et POST.
Ce qui est utilisé vous appartient. Mais n'oubliez pas d'utiliser le bon en fonction de l'objet auquel vous faites référence dans la demande.
Quelques considérations:
Un exemple:
J'ai écrit ce qui suit dans le cadre d'une autre réponse sur SO à ce sujet :
De plus, et un peu plus concis, la RFC 7231 Section 4.3.4 PUT déclare (non souligné dans l'original),
la source
Vous pouvez trouver des affirmations sur le Web qui disent
Ni l'un ni l'autre n'a tout à fait raison.
Mieux vaut choisir entre PUT et POST en fonction de l' idempotence de l'action.
PUT implique de mettre une ressource - en remplaçant complètement tout ce qui est disponible à l'URL donnée par une chose différente. Par définition, un PUT est idempotent. Faites-le autant de fois que vous le souhaitez et le résultat est le même.
x=5
est idempotent. Vous pouvez METTRE une ressource qu'elle existe ou non (par exemple, pour créer ou mettre à jour)!POST met à jour une ressource, ajoute une ressource subsidiaire ou provoque une modification. Un POST n'est pas idempotent, de la même manière qu'il
x++
n'est pas idempotent.Par cet argument, PUT sert à créer lorsque vous connaissez l'URL de la chose que vous allez créer. POST peut être utilisé pour créer lorsque vous connaissez l'URL de la «fabrique» ou du gestionnaire pour la catégorie de choses que vous souhaitez créer.
donc:
ou:
la source
name
etdate
. Si nous avons une entité avec un existantname
etdate
, mais que nous lui demandons ensuite en spécifiant seulement unname
, le bon comportement de PUT serait d'effacer ledate
de l'entité, alors que POST peut mettre à jour uniquement les propriétés spécifiées, en laissant les propriétés non spécifiées telles qu'elles étaient avant la demande. Est-ce que cela semble correct / raisonnable, ou s'agit-il d'une mauvaise utilisation de PUT (j'ai vu des références à PATCH , ce qui semble être plus approprié, mais n'existe pas encore)?La spécification pertinente pour PUT et POST est RFC 2616 §9.5ff.
POST crée une ressource enfant , donc POST
/items
crée des ressources qui vivent sous la/items
ressource. Par exemple./items/1
. L'envoi du même post-paquet deux fois créera deux ressources.PUT sert à créer ou à remplacer une ressource à une URL connue du client .
Par conséquent: PUT est uniquement un candidat pour CREATE où le client connaît déjà l'URL avant la création de la ressource. Par exemple.
/blogs/nigel/entry/when_to_use_post_vs_put
car le titre est utilisé comme clé de ressourcePUT remplace la ressource à l'url connue si elle existe déjà, donc envoyer deux fois la même demande n'a aucun effet. En d'autres termes, les appels à PUT sont idempotents .
Le RFC se lit comme suit:
Remarque: PUT a été principalement utilisé pour mettre à jour les ressources (en les remplaçant dans leur intégralité), mais récemment, on s'oriente vers l'utilisation de PATCH pour mettre à jour les ressources existantes, car PUT spécifie qu'il remplace la ressource entière. RFC 5789.
Mise à jour 2018 : il y a un cas qui peut être fait pour éviter le PUT. Voir "REST sans PUT"
extrait de REST API Design - Modélisation des ressources par Prakash Subramaniam de Thoughtworks
Cela oblige l'API à éviter les problèmes de transition d'état avec plusieurs clients mettant à jour une seule ressource, et correspond mieux avec le sourcing d'événements et le CQRS. Lorsque le travail est effectué de manière asynchrone, POSTER la transformation et attendre qu'elle soit appliquée semble approprié.
la source
Sommaire:
Créer:
Peut être effectué avec PUT ou POST de la manière suivante:
Mise à jour:
Ne peut être exécuté avec PUT que de la manière suivante:
Explication:
Lorsque vous traitez REST et URI en général, vous avez générique à gauche et spécifique à droite . Les génériques sont généralement appelés collections et les éléments plus spécifiques peuvent être appelés ressource . Notez qu'une ressource peut contenir une collection .
Lorsque vous utilisez POST, vous vous référez toujours à une collection , donc chaque fois que vous dites:
vous publiez un nouvel utilisateur dans la collection d' utilisateurs .
Si vous continuez et essayez quelque chose comme ceci:
cela fonctionnera, mais sémantiquement vous dites que vous voulez ajouter une ressource à la collection john sous la collection users .
Une fois que vous utilisez PUT, vous vous référez à une ressource ou à un élément unique, éventuellement à l'intérieur d'une collection . Donc, quand vous dites:
vous dites à la mise à jour du serveur, ou créez si elle n'existe pas, la ressource john sous la collection users .
Spec:
Permettez-moi de souligner certaines parties importantes de la spécification:
PUBLIER
Par conséquent, crée une nouvelle ressource sur une collection .
METTRE
Par conséquent, créez ou mettez à jour en fonction de l'existence de la ressource .
Référence:
la source
POST
signifie "créer un nouveau" comme dans "Voici l'entrée pour créer un utilisateur, créez-le pour moi".PUT
signifie "insérer, remplacer s'il existe déjà" comme dans "Voici les données pour l'utilisateur 5".Vous
POST
à example.com/users puisque vous ne connaissez pas encore l'URL
utilisateur, vous voulez que le serveur le crée.Vous
PUT
à example.com/users/id puisque vous souhaitez remplacer / créer un utilisateur spécifique .POSTER deux fois avec les mêmes données signifie créer deux utilisateurs identiques avec des identifiants différents. PUT deux fois avec les mêmes données crée l'utilisateur le premier et le met à jour au même état la deuxième fois (pas de changement). Puisque vous vous retrouvez avec le même état après un
PUT
nombre de fois que vous l'exécutez, il est dit à chaque fois "tout aussi puissant" - idempotent. Ceci est utile pour réessayer automatiquement les demandes. Vous n'êtes plus sûr de vouloir renvoyer lorsque vous appuyez sur le bouton de retour du navigateur.Un conseil général est à utiliser
POST
lorsque vous avez besoin que le serveur contrôle laURL
génération de vos ressources. UtilisezPUT
autrement. PréférezPUT
plusPOST
.la source
user 5
s'il n'existe pas encore? Tu ne veux pas direupdate, replace if already exists
? ou quelque chosePUT
peut également être utilisé pour remplacer la valeur d'une ressource existante dans son intégralité.Je voudrais ajouter mon conseil "pragmatique". Utilisez PUT lorsque vous connaissez l '"id" par lequel l'objet que vous enregistrez peut être récupéré. L'utilisation de PUT ne fonctionnera pas trop bien si vous avez besoin, par exemple, d'un identifiant généré par la base de données à renvoyer pour que vous puissiez effectuer des recherches ou des mises à jour futures.
Donc: pour enregistrer un utilisateur existant, ou celui où le client génère l'ID et il a été vérifié que l'ID est unique:
Sinon, utilisez POST pour créer initialement l'objet et PUT pour mettre à jour l'objet:
la source
POST /users
. (Notez qu'il/users
est au pluriel.) Cela a pour effet de créer un nouvel utilisateur et d'en faire une ressource enfant de la/users
collection.GET /users
est logique, il se lit comme vous le souhaitez, mais je serais d'accord avecGET /user/<id>
ouPOST /user
(avec la charge utile pour ledit nouvel utilisateur) car il lit correctement `` get me users 5 '' est étrange, mais `` get me user 5 '' est plus naturel. Je tomberais probablement toujours du côté de la pluralisation cependant :)Utilisez POST pour créer et PUT pour mettre à jour. Voilà comment Ruby on Rails le fait, de toute façon.
la source
POST /items
ajoute un nouvel élément à une ressource déjà définie («élément»). Il ne s'agit pas, comme le dit la réponse, de "créer un groupe". Je ne comprends pas pourquoi cela a 12 voix.PUT /items/42
est également valable pour la création d' une ressource, mais uniquement si le client a le privilège de nommer la ressource . (Est-ce que RailsLes deux sont utilisés pour la transmission de données entre le client et le serveur, mais il existe de subtiles différences entre eux, qui sont:
Analogie:
Analogie des réseaux sociaux / réseaux:
la source
REST est un concept de très haut niveau. En fait, il ne mentionne même pas du tout HTTP!
Si vous avez des doutes sur la façon d'implémenter REST dans HTTP, vous pouvez toujours jeter un œil à la spécification Atom Publication Protocol (AtomPub) . AtomPub est un standard pour l'écriture de services Web RESTful avec HTTP qui a été développé par de nombreux luminaires HTTP et REST, avec une contribution de Roy Fielding, l'inventeur de REST et (co-) inventeur de HTTP lui-même.
En fait, vous pourriez même être en mesure d'utiliser directement AtomPub. Bien qu'il soit issu de la communauté des blogueurs, il n'est en aucun cas limité aux blogs: c'est un protocole générique pour interagir RESTfully avec des collections arbitraires (imbriquées) de ressources arbitraires via HTTP. Si vous pouvez représenter votre application comme une collection imbriquée de ressources, vous pouvez simplement utiliser AtomPub et ne pas vous soucier d'utiliser PUT ou POST, les codes d'état HTTP à renvoyer et tous ces détails.
Voici ce qu'AtomPub a à dire sur la création de ressources (section 9.2):
la source
La décision d'utiliser PUT ou POST pour créer une ressource sur un serveur avec une API HTTP + REST est basée sur le propriétaire de la structure URL. La connaissance ou la participation du client à la définition de la structure de l'URL est un couplage inutile semblable aux couplages indésirables résultant de SOA. Les types de raccords d'échappement sont la raison pour laquelle REST est si populaire. Par conséquent, la méthode appropriée à utiliser est POST. Il existe des exceptions à cette règle et elles se produisent lorsque le client souhaite conserver le contrôle de la structure de localisation des ressources qu'il déploie. C'est rare et signifie probablement que quelque chose d'autre ne va pas.
À ce stade, certaines personnes diront que si des URL RESTful sont utilisées, le client connaît l'URL de la ressource et donc un PUT est acceptable. Après tout, c'est pourquoi les URL canoniques, normalisées, Ruby on Rails, Django sont importantes, regardez l'API Twitter… bla bla bla. Ces personnes doivent comprendre qu'il n'y a pas d'URL reposante et que Roy Fielding lui-même déclare que :
L'idée d'une URL RESTful est en fait une violation de REST car le serveur est responsable de la structure de l'URL et devrait être libre de décider comment l'utiliser pour éviter le couplage. Si cela vous embrouille, lisez l'importance de la découverte de soi sur la conception d'API.
L'utilisation de POST pour créer des ressources s'accompagne d'une considération de conception car POST n'est pas idempotent. Cela signifie que la répétition d'un POST plusieurs fois ne garantit pas le même comportement à chaque fois. Cela fait peur aux gens d'utiliser PUT pour créer des ressources alors qu'ils ne devraient pas. Ils savent que c'est faux (POST est pour CREATE) mais ils le font quand même parce qu'ils ne savent pas comment résoudre ce problème. Cette préoccupation se manifeste dans la situation suivante:
L'étape 6 est l'endroit où les gens se trompent généralement sur ce qu'il faut faire. Cependant, il n'y a aucune raison de créer un kludge pour résoudre ce problème. Au lieu de cela, HTTP peut être utilisé comme spécifié dans RFC 2616 et le serveur répond:
Répondre avec un code d'état 409 Conflit est le bon recours car :
Mise à jour basée sur la publication de RFC 7231 pour remplacer 2616
RFC 7231 est conçu pour remplacer 2616 et dans la section 4.3.3 décrit la réponse possible suivante pour un POST
Il peut maintenant être tentant de renvoyer simplement un 303 dans le cas où un POST est répété. Cependant, l'inverse est vrai. Renvoyer un 303 n'aurait de sens que si plusieurs demandes de création (création de ressources différentes) renvoient le même contenu. Un exemple serait un «merci d'avoir soumis votre message de demande» que le client n'a pas besoin de re-télécharger à chaque fois. La RFC 7231 maintient toujours dans la section 4.2.2 que le POST ne doit pas être idempotent et continue de maintenir que le POST doit être utilisé pour la création.
Pour plus d'informations à ce sujet, lisez cet article .
la source
J'aime ce conseil, de la définition RFC 2616 de PUT :
Cela concorde avec l'autre conseil ici, que PUT est mieux appliqué aux ressources qui ont déjà un nom, et POST est bon pour créer un nouvel objet sous une ressource existante (et laisser le serveur le nommer).
J'interprète cela, et les exigences d'idempotence sur PUT, pour signifier que:
la source
En bref:
METTRE est idempotent, où l'état de la ressource sera le même si la même opération est exécutée une ou plusieurs fois.
PUBLIER n'est pas idempotent, où l'état des ressources peut devenir différent si l'opération est exécutée plusieurs fois par rapport à l'exécution d'une seule fois.
Analogie avec requête de base de données
METTRE Vous pouvez penser à similaire à "UPDATE STUDENT SET address =" abc "where id =" 123 ";
PUBLIER Vous pouvez penser à quelque chose comme "INSERT IN STUDENT (nom, adresse) VALEURS (" abc "," xyzzz ");
L'ID étudiant est généré automatiquement.
Avec PUT, si la même requête est exécutée plusieurs fois ou une fois, l'état de la table STUDENT reste le même.
En cas de POST, si la même requête est exécutée plusieurs fois, plusieurs enregistrements Student sont créés dans la base de données et l'état de la base de données change à chaque exécution d'une requête "INSERT".
REMARQUE: PUT a besoin d'un emplacement de ressource (déjà ressource) sur lequel la mise à jour doit avoir lieu, alors que POST ne l'exige pas. Par conséquent, intuitivement, POST est destiné à la création d'une nouvelle ressource, tandis que PUT est nécessaire pour mettre à jour la ressource déjà existante.
Certains peuvent proposer que les mises à jour puissent être effectuées avec POST. Il n'y a pas de règle stricte à utiliser pour les mises à jour ou à utiliser pour créer. Encore une fois, ce sont des conventions, et intuitivement je suis enclin au raisonnement mentionné ci-dessus et le suis.
la source
POST, c'est comme publier une lettre dans une boîte aux lettres ou poster un e-mail dans une file d'attente d'emails. PUT, c'est comme lorsque vous placez un objet dans un compartiment ou un endroit sur une étagère (il a une adresse connue).
Avec POST, vous publiez à l'adresse de la QUEUE ou de la COLLECTION. Avec PUT, vous mettez à l'adresse de l'ARTICLE.
PUT est idempotent. Vous pouvez envoyer la demande 100 fois et cela n'aura pas d'importance. POST n'est pas idempotent. Si vous envoyez la demande 100 fois, vous recevrez 100 e-mails ou 100 lettres dans votre boîte postale.
Une règle générale: si vous connaissez l'identifiant ou le nom de l'article, utilisez PUT. Si vous souhaitez que l'ID ou le nom de l'élément soit attribué par le destinataire, utilisez POST.
la source
Nouvelle réponse (maintenant que je comprends mieux REST):
PUT est simplement une déclaration du contenu que le service devrait désormais utiliser pour rendre des représentations de la ressource identifiée par le client; POST est une déclaration du contenu que le service doit désormais contenir (éventuellement dupliqué), mais c'est au serveur comment identifier ce contenu.
PUT x
(six
identifie une ressource ): "Remplacez le contenu de la ressource identifiée parx
par mon contenu."PUT x
(six
n'identifie pas une ressource): "Créer une nouvelle ressource contenant mon contenu et l'utiliserx
pour l'identifier."POST x
: "Stockez mon contenu et donnez-moi un identifiant que je peux utiliser pour identifier une ressource (ancienne ou nouvelle) contenant ledit contenu (éventuellement mélangé à d'autres contenus). Cette ressource doit être identique ou subordonnée à celle qui l'x
identifie." « Y « de la ressource est subordonnée à x » ressource s » est généralement , mais pas nécessairement mis en œuvre en faisant y un sous - chemin de x (par exemple x =/foo
et y =/foo/bar
) et modifier la représentation (s) de x ressources de l » afin de refléter l'existence d'une nouvelle ressource, par exemple avec un hyperlien vers yressources et quelques métadonnées. Seul ce dernier est vraiment essentiel à une bonne conception, car les URL sont opaques dans REST - vous êtes censé utiliser l'hypermédia au lieu de la construction d'URL côté client pour traverser le service de toute façon.Dans REST, il n'y a pas de ressource contenant du "contenu". J'appelle «contenu» les données que le service utilise pour rendre les représentations de manière cohérente. Il se compose généralement de quelques lignes associées dans une base de données ou un fichier (par exemple, un fichier image). C'est au service de convertir le contenu de l'utilisateur en quelque chose que le service peut utiliser, par exemple convertir une charge utile JSON en instructions SQL.
Réponse originale (peut être plus facile à lire) :
PUT /something
(s'il/something
existe déjà): "Prenez tout ce que vous avez/something
et remplacez-le par ce que je vous donne."PUT /something
(s'il/something
n'existe pas déjà): "Prenez ce que je vous donne et mettez-le/something
."POST /something
: "Prends ce que je te donne et mets-le où tu veux/something
tant que tu me donnes son URL quand tu auras fini."la source
Réponse courte:
Règle générale simple: utilisez POST pour créer, utilisez PUT pour mettre à jour.
Longue réponse:
PUBLIER:
METTRE:
Réponse plus longue:
Pour le comprendre, nous devons nous demander pourquoi PUT était requis, quels étaient les problèmes que PUT essayait de résoudre et que POST ne pouvait pas résoudre.
Du point de vue d'une architecture REST, il n'y en a pas qui compte. Nous aurions pu vivre sans PUT également. Mais du point de vue d'un développeur client, cela a rendu sa vie beaucoup plus simple.
Avant PUT, les clients ne pouvaient pas savoir directement l'URL que le serveur avait générée ou si tout ce qu'il avait généré ou si les données à envoyer au serveur étaient déjà mises à jour ou non. PUT a soulagé le développeur de tous ces maux de tête. PUT est idempotent, PUT gère les conditions de concurrence et PUT laisse le client choisir l'URL.
la source
Ruby on Rails 4.0 utilisera la méthode 'PATCH' au lieu de PUT pour effectuer des mises à jour partielles.
RFC 5789 dit à propos de PATCH (depuis 1995):
" Edge Rails: PATCH est la nouvelle méthode HTTP principale pour les mises à jour ", explique-t-il.
la source
Au risque de reformuler ce qui a déjà été dit, il semble important de se rappeler que PUT implique que le client contrôle ce que l' URL finira par être, lors de la création d'une ressource. Donc, une partie du choix entre PUT et POST sera de savoir dans quelle mesure vous pouvez faire confiance au client pour fournir une URL correcte et normalisée qui soit cohérente avec votre schéma d'URL.
Lorsque vous ne pouvez pas entièrement faire confiance au client pour faire la bonne chose, il serait plus approprié d'utiliser POST pour créer un nouvel élément, puis de renvoyer l'URL au client dans la réponse.
la source
Location
tête qui ne contient le nom de la ressource canonique.PUT /X-files/series/4/episodes/max
) et le serveur répond avec un URI qui fournit un court lien canonique unique vers cette nouvelle ressource (c.-à-d./X-Ffiles/episodes/91
)D'une manière très simple, je prends l'exemple de la chronologie Facebook.
Cas 1: Lorsque vous postez quelque chose sur votre chronologie, c'est une nouvelle entrée. Dans ce cas, ils utilisent donc la méthode POST car la méthode POST n'est pas idempotente.
Cas 2: Si votre ami commente votre message pour la première fois, cela créera également une nouvelle entrée dans la base de données afin que la méthode POST soit utilisée.
Cas 3: Si votre ami modifie son commentaire, dans ce cas, il avait un identifiant de commentaire, il mettra donc à jour un commentaire existant au lieu de créer une nouvelle entrée dans la base de données. Par conséquent, pour ce type d'opération, utilisez la méthode PUT car elle est idempotente. *
Sur une seule ligne, utilisez POST pour ajouter une nouvelle entrée dans la base de données et PUT pour mettre à jour quelque chose dans la base de données.
la source
La considération la plus importante est la fiabilité . Si un message POST est perdu, l'état du système n'est pas défini. La récupération automatique est impossible. Pour les messages PUT, l'état n'est indéfini que jusqu'à la première tentative réussie.
Par exemple, il peut ne pas être judicieux de créer des transactions par carte de crédit avec POST.
S'il vous arrive d'avoir des URI générés automatiquement sur votre ressource, vous pouvez toujours utiliser PUT en passant un URI généré (pointant vers une ressource vide) au client.
Quelques autres considérations:
la source
Les lecteurs de nouvelles à ce sujet seront frappés par la discussion sans fin sur ce que vous devriez faire, et l'absence relative des enseignements tirés de l' expérience. Le fait que REST soit "préféré" par rapport à SOAP est, je suppose, un apprentissage de haut niveau par expérience, mais bonté, nous devons avoir progressé à partir de là? Nous sommes en 2016. La thèse de Roy remonte à 2000. Qu'avons-nous développé? C'était amusant? A-t-il été facile de s'intégrer avec? Soutenir? Va-t-il gérer la montée en puissance des smartphones et des connexions mobiles feuilletées?
Selon ME, les réseaux réels ne sont pas fiables. Délai d'expiration des demandes. Les connexions sont réinitialisées. Les réseaux tombent pendant des heures ou des jours à la fois. Les trains entrent dans les tunnels avec des utilisateurs mobiles à bord. Pour toute demande donnée (comme cela a parfois été reconnu dans toute cette discussion), la demande peut tomber dans l'eau sur son chemin, ou la réponse peut tomber dans l'eau sur le chemin du retour. Dans ces conditions, émettre des demandes PUT, POST et DELETE directement contre des ressources substantielles m'a toujours paru un peu brutal et naïf.
HTTP ne fait rien pour assurer une exécution fiable de la demande-réponse, et c'est très bien car c'est bien le travail des applications réseau. En développant une telle application, vous pouvez sauter à travers les cercles pour utiliser PUT au lieu de POST, puis plus de cercles pour donner un certain type d'erreur sur le serveur si vous détectez des demandes en double. De retour chez le client, vous devez ensuite sauter à travers des cerceaux pour interpréter ces erreurs, récupérer, revalider et republier.
Ou vous pouvez le faire : considérez vos demandes dangereuses comme des ressources éphémères pour un seul utilisateur (appelons-les actions). Les clients demandent une nouvelle "action" sur une ressource substantielle avec un POST vide à la ressource. POST ne sera utilisé que pour cela. Une fois en possession de l'URI de l'action fraîchement émise, le client transmet la demande non sécurisée à l'URI de l'action, et non à la ressource cible . La résolution de l'action et la mise à jour de la "vraie" ressource est correctement l'affaire de votre API, et est ici découplée du réseau peu fiable.
Le serveur fait l'affaire, renvoie la réponse et la stocke par rapport à l'URI d'action convenu . Si quelque chose ne va pas, le client répète la requête (comportement naturel!), Et si le serveur l'a déjà vue, il répète la réponse stockée et ne fait rien d'autre .
Vous remarquerez rapidement la similitude avec les promesses: nous créons et renvoyons l'espace réservé pour le résultat avant de faire quoi que ce soit. Comme une promesse, une action peut réussir ou échouer une seule fois, mais son résultat peut être récupéré à plusieurs reprises.
Mieux encore, nous donnons aux demandes d'envoi et de réception la possibilité de lier l'action identifiée de manière unique à l'unicité de leurs environnements respectifs. Et nous pouvons commencer à exiger et à appliquer !, un comportement responsable de la part des clients: répétez vos demandes autant que vous le souhaitez, mais ne générez pas de nouvelle action tant que vous n'êtes pas en possession d'un résultat définitif de l'action existante.
Ainsi, de nombreux problèmes épineux disparaissent. Les demandes d'insertion répétées ne créeront pas de doublons, et nous ne créons pas la véritable ressource tant que nous ne sommes pas en possession des données. (les colonnes de la base de données peuvent rester non nulles). Les demandes de mise à jour répétées n'atteindront pas les états incompatibles et n'écraseront pas les modifications ultérieures. Les clients peuvent (re) récupérer et traiter de manière transparente la confirmation d'origine pour une raison quelconque (le client est tombé en panne, la réponse a disparu, etc.).
Les demandes de suppression successives peuvent voir et traiter la confirmation d'origine, sans générer d'erreur 404. Si les choses prennent plus de temps que prévu, nous pouvons répondre provisoirement et nous avons un endroit où le client peut vérifier le résultat définitif. La plus belle partie de ce modèle est sa propriété Kung-Fu (Panda). Nous prenons une faiblesse, la propension des clients à répéter une demande chaque fois qu'ils ne comprennent pas la réponse, et la transformons en force :-)
Avant de me dire que ce n'est pas RESTful, veuillez considérer les nombreuses façons dont les principes REST sont respectés. Les clients ne construisent pas d'URL. L'API reste découvrable, mais avec un petit changement de sémantique. Les verbes HTTP sont utilisés de manière appropriée. Si vous pensez que c'est un énorme changement à mettre en œuvre, je peux vous dire par expérience que ce n'est pas le cas.
Si vous pensez que vous aurez d'énormes quantités de données à stocker, parlons de volumes: une confirmation de mise à jour typique est une fraction de kilo-octet. HTTP vous donne actuellement une minute ou deux pour répondre définitivement. Même si vous ne stockez les actions que pendant une semaine, les clients ont amplement l'occasion de se rattraper. Si vous avez des volumes très élevés, vous souhaiterez peut-être un magasin de valeurs de clés conforme à l'acide dédié ou une solution en mémoire.
la source
En plus des différences suggérées par d'autres, je veux en ajouter une de plus.
Dans la méthode POST , vous pouvez envoyer des paramètres de corps dans
form-data
Dans la méthode PUT , vous devez envoyer les paramètres du corps dans
x-www-form-urlencoded
Entête
Content-Type:application/x-www-form-urlencoded
Selon cela, vous ne pouvez pas envoyer de fichiers ou de données en plusieurs parties dans la méthode PUT
ÉDITER
Ce qui signifie que si vous devez soumettre
vous devez utiliser la méthode POST
la source
Il semble toujours y avoir une certaine confusion quant au moment d'utiliser HTTP POST par rapport à la méthode HTTP PUT pour les services REST. La plupart des développeurs essaieront d'associer les opérations CRUD directement aux méthodes HTTP. Je soutiendrai que ce n'est pas correct et que l'on ne peut pas simplement associer les concepts CRUD aux méthodes HTTP. C'est:
Il est vrai que le R (etrieve) et le D (elete) des opérations CRUD peuvent être mappés directement aux méthodes HTTP GET et DELETE respectivement. Cependant, la confusion réside dans les opérations C (reate) et U (update). Dans certains cas, on peut utiliser le PUT pour une création tandis que dans d'autres cas, un POST sera nécessaire. L'ambiguïté réside dans la définition d'une méthode HTTP PUT par rapport à une méthode HTTP POST.
Selon les spécifications HTTP 1.1, les méthodes GET, HEAD, DELETE et PUT doivent être idempotentes et la méthode POST n'est pas idempotente. C'est-à-dire qu'une opération est idempotente si elle peut être effectuée sur une ressource une ou plusieurs fois et toujours retourner le même état de cette ressource. Alors qu'une opération non idempotente peut renvoyer un état modifié de la ressource d'une requête à l'autre. Par conséquent, dans une opération non idempotente, rien ne garantit que l'on recevra le même état d'une ressource.
Sur la base de la définition idempotente ci-dessus, mon point de vue sur l'utilisation de la méthode HTTP PUT par rapport à l'utilisation de la méthode HTTP POST pour les services REST est: Utilisez la méthode HTTP PUT lorsque:
Dans les deux cas, ces opérations peuvent être effectuées plusieurs fois avec les mêmes résultats. Autrement dit, la ressource ne sera pas modifiée en demandant l'opération plus d'une fois. D'où une véritable opération idempotente. Utilisez la méthode HTTP POST lorsque:
Conclusion
Ne corrélez pas et ne mappez pas directement les opérations CRUD aux méthodes HTTP pour les services REST. L'utilisation d'une méthode HTTP PUT par rapport à une méthode HTTP POST doit être basée sur l'aspect idempotent de cette opération. Autrement dit, si l'opération est idempotente, utilisez la méthode HTTP PUT. Si l'opération n'est pas idempotente, utilisez la méthode HTTP POST.
la source
Vous utilisez donc POST et probablement, mais pas nécessaire PUT pour la création de ressources. Vous n'avez pas à supporter les deux. Pour moi, POST est parfaitement suffisant. C'est donc une décision de conception.
Comme votre citation l'a mentionné, vous utilisez PUT pour la création d'aucune ressource affectée à un IRI, et vous voulez quand même créer une ressource. Par exemple,
PUT /users/123/password
remplace généralement l'ancien mot de passe par un nouveau, mais vous pouvez l'utiliser pour créer un mot de passe s'il n'existe pas déjà (par exemple, par des utilisateurs fraîchement enregistrés ou en restaurant des utilisateurs interdits).la source
Je vais atterrir avec ce qui suit:
PUT fait référence à une ressource, identifiée par l'URI. Dans ce cas, vous le mettez à jour. C'est la partie des trois verbes se référant aux ressources - supprimer et devenir les deux autres.
POST est essentiellement un message de forme libre, sa signification étant définie «hors bande». Si le message peut être interprété comme l'ajout d'une ressource à un répertoire, ce serait OK, mais fondamentalement, vous devez comprendre le message que vous envoyez (publier) pour savoir ce qui se passera avec la ressource.
Parce que PUT et GET et DELETE font référence à une ressource, ils sont également par définition idempotents.
POST peut effectuer les trois autres fonctions, mais alors la sémantique de la demande sera perdue sur les intermédiaires tels que les caches et les proxys. Cela s'applique également à la sécurité de la ressource, car l'URI d'un article n'indique pas nécessairement la ressource à laquelle il s'applique (il peut cependant).
Un PUT n'a pas besoin d'être une création; le service peut générer une erreur si la ressource n'est pas déjà créée, mais sinon la mettre à jour. Ou vice versa - il peut créer la ressource, mais ne pas autoriser les mises à jour. La seule chose requise à propos de PUT est qu'il pointe vers une ressource spécifique, et sa charge utile est la représentation de cette ressource. Un PUT réussi signifie (sauf interférence) qu'un GET récupérerait la même ressource.
Edit: Encore une chose - un PUT peut créer, mais si c'est le cas, l'ID doit être un ID naturel - AKA une adresse e-mail. De cette façon, lorsque vous mettez deux fois, le deuxième put est une mise à jour du premier. Cela le rend idempotent .
Si l'ID est généré (un nouvel ID d'employé, par exemple), le deuxième PUT avec la même URL créerait un nouvel enregistrement, ce qui viole la règle idempotente. Dans ce cas, le verbe serait POST et le message (pas une ressource) serait de créer une ressource en utilisant les valeurs définies dans ce message.
la source
La sémantique est supposée être différente, dans la mesure où "PUT", comme "GET" est censé être idempotent - ce qui signifie que vous pouvez répéter la même demande PUT exacte plusieurs fois et le résultat sera comme si vous ne l'aviez exécuté qu'une seule fois.
Je décrirai les conventions qui, selon moi, sont les plus utilisées et les plus utiles:
Lorsque vous METTEZ une ressource sur une URL particulière, ce qui se passe, c'est qu'elle doit être enregistrée sur cette URL, ou quelque chose du genre.
Lorsque vous publiez sur une ressource à une URL particulière, vous publiez souvent une information associée à cette URL. Cela implique que la ressource à l'URL existe déjà.
Par exemple, lorsque vous souhaitez créer un nouveau flux, vous pouvez le METTRE vers une URL. Mais lorsque vous souhaitez POSTER un message sur un flux existant, vous POSTEZ sur son URL.
Quant à la modification des propriétés du flux, vous pouvez le faire avec PUT ou POST. Fondamentalement, utilisez uniquement "PUT" lorsque l'opération est idempotente - sinon utilisez POST.
Notez cependant que tous les navigateurs modernes ne prennent pas en charge les verbes HTTP autres que GET ou POST.
la source
La plupart du temps, vous les utiliserez comme ceci:
Par exemple:
Dans les deux cas, le corps de la demande contient les données de la ressource à créer ou à mettre à jour. Il devrait être évident d'après les noms de route que POST n'est pas idempotent (si vous l'appelez 3 fois cela créera 3 objets), mais PUT est idempotent (si vous l'appelez 3 fois le résultat est le même). PUT est souvent utilisé pour une opération "upsert" (création ou mise à jour), mais vous pouvez toujours renvoyer une erreur 404 si vous ne souhaitez l'utiliser que pour le modifier.
Notez que POST "crée" un nouvel élément dans la collection et PUT "remplace" un élément à une URL donnée, mais il est très courant d'utiliser PUT pour des modifications partielles, c'est-à-dire de ne l'utiliser que pour mettre à jour les ressources existantes et modifier uniquement les champs inclus dans le corps (en ignorant les autres champs). Ceci est techniquement incorrect, si vous voulez être puriste REST, PUT doit remplacer la ressource entière et vous devez utiliser PATCH pour la mise à jour partielle. Personnellement, je ne m'inquiète pas tant que le comportement est clair et cohérent sur tous vos points de terminaison API.
N'oubliez pas que REST est un ensemble de conventions et de directives pour garder votre API simple. Si vous vous retrouvez avec un contournement compliqué juste pour cocher la case "RESTfull" alors vous allez à l'encontre du but;)
la source
Bien qu'il existe probablement une façon agnostique de les décrire, cela semble être en conflit avec diverses déclarations provenant des réponses aux sites Web.
Soyons très clairs et directs ici. Si vous êtes un développeur .NET travaillant avec l'API Web, les faits sont (à partir de la documentation de l'API Microsoft), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web -api-that-supports-crud-operations :
Bien sûr, vous "pouvez" utiliser "POST" pour effectuer la mise à jour, mais suivez simplement les conventions qui vous sont proposées avec votre framework donné. Dans mon cas, c'est .NET / Web API, donc PUT est pour UPDATE il n'y a pas de débat.
J'espère que cela aidera tous les développeurs Microsoft qui liront tous les commentaires avec des liens vers des sites Web Amazon et Sun / Java.
la source
Voici une règle simple:
PUT vers une URL doit être utilisé pour mettre à jour ou créer la ressource qui peut se trouver sur cette URL.
POST vers une URL doit être utilisé pour mettre à jour ou créer une ressource qui se trouve sur une autre URL ("subordonnée"), ou qui n'est pas localisable via HTTP.
la source
Si vous connaissez les opérations de base de données, il existe
J'utilise
PUT
pour la fusion et la mise à jour comme des opérations et j'utilisePOST
pour les insertions.la source
En pratique, POST fonctionne bien pour créer des ressources. L'URL de la ressource nouvellement créée doit être renvoyée dans l'en-tête de réponse Emplacement. PUT doit être utilisé pour mettre à jour une ressource complètement. Veuillez comprendre qu'il s'agit des meilleures pratiques lors de la conception d'une API RESTful. La spécification HTTP en tant que telle ne restreint pas l'utilisation de PUT / POST avec quelques restrictions pour la création / mise à jour des ressources. Jetez un œil à http://techoctave.com/c7/posts/71-twitter-rest-api-dissected qui résume les meilleures pratiques.
la source