REST - Ne devrait pas PUT = Créer et POST = Mise à jour
PUTne devrait pas être utilisé pour Create etPOSTutilisé pour Update puisque PUT est idempotent.
De cette façon, plusieurs PUT pour le même ordre ne placeront qu’un seul ordre?
La différence est qu’un PUT concerne une ressource connue, et donc utilisé pour la mise à jour, comme indiqué ici dans RFC2616.
La différence fondamentale entre les requêtes POST et PUT est reflété dans la signification différente de l'URI de demande. L'URI dans un La demande POST identifie la ressource qui gérera le .__ inclus. entité. Cette ressource peut être un processus acceptant les données, une passerelle vers un autre protocole, ou une entité distincte qui accepte les annotations. Dans En revanche, l’URI dans une requête PUT identifie l’entité jointe à la demande - l'agent utilisateur sait ce que l'URI est destiné et le le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource.
Je vois cependant d'où vous venez en vous basant sur les noms eux-mêmes.
Je regarde habituellement POST comme il devrait être l'URI qui gérera le contenu de ma requête (dans la plupart des cas, les paramètres comme des valeurs de formulaire) et créant ainsi une nouvelle ressource, et PUT comme l'URI faisant l'objet de ma demande (/ users/1234), une ressource qui existe déjà.
Je pense que la nomenclature remonte loin dans le temps, considérons le Web à ses débuts. On peut vouloir POST leur message sur un forum, puis PUT un contenu supplémentaire dans leur message à une date ultérieure.
PUT doit être utilisé pour crée si et seulement si possible, l'URI de la nouvelle ressource est connu pour un client. Un nouvel URI peut être annoncé par le service dans la représentation des ressources. Par exemple, le service peut fournir un type de formulaire de soumission et spécifier une adresse URI d'action, qui peut être une adresse URI préremplie de la nouvelle ressource. Dans ce cas, oui, si la demande PUT initiale crée correctement la ressource, la demande PUT ne la remplacera que.
Il est correct d'utiliser POST pour les mises à jour, il n'a jamais été dit que POST ne concerne que les opérations "créer".
Il n'y a pas de correspondance stricte entre les méthodes HTTP et CRUD. C'est une convention adoptée par certains cadres, mais cela n'a rien à voir avec les contraintes REST.
Une requête PUT demande au serveur de remplacer tout ce qui se trouve à l'URI donné par la représentation incluse, en ignorant complètement le contenu actuel. Une bonne analogie est la commande mv dans un shell. Il crée le nouveau fichier à la destination s’il n’existe pas ou remplace ce qui existe. Dans les deux cas, il ignore complètement tout ce qui s'y trouve. Vous pouvez utiliser ceci pour créer, mais aussi pour mettre à jour quelque chose, à condition d'envoyer une représentation complète.
POST demande à la ressource cible de traiter la charge conformément à des règles prédéfinies. Il s'agit donc de la méthode à utiliser pour toute opération qui n'est pas déjà normalisée par le protocole HTTP. Cela signifie qu'une POST peut faire tout ce que vous voulez, tant que vous ne dupliquez pas la fonctionnalité d'une autre méthode - par exemple, en utilisant POST pour la récupération alors que vous devriez utiliser GET - et que vous la documentez correctement.
Ainsi, vous pouvez utiliser à la fois pour créer et mettre à jour, selon les circonstances, mais avec PUT, vous devez avoir une sémantique cohérente pour tout dans votre API et vous ne pouvez pas effectuer de mises à jour partielles. Avec POST, vous pouvez faire tout ce que vous voulez, comme Tant que vous documentez comment cela fonctionne exactement.
Cela dépend ... vous pouvez créer/mettre à jour des sites/enregistrements avec les deux .. Lorsque le client spécifie l'URI, PUT est le chemin à parcourir .. Par exemple. N'importe quel éditeur de code comme Dreamweaver, PUT est le bon protocole à utiliser.
regardez aussi ce sujet: put vs post in repos