Quelle est la principale différence entre la requête PATCH et PUT?


187

J'utilise une PUTrequête dans mon application Rails. Maintenant, un nouveau verbe HTTP PATCHa été implémenté par les navigateurs. Donc, je veux savoir quelle est la principale différence entre PATCHet les PUTdemandes, et quand nous devrions utiliser l'un ou l'autre.

Réponses:


139

Les verbes HTTP sont probablement l'une des choses les plus cryptiques du protocole HTTP. Ils existent, et il y en a beaucoup, mais pourquoi existent-ils?

Rails semble vouloir prendre en charge de nombreux verbes et ajouter des verbes qui ne sont pas pris en charge par les navigateurs Web de manière native.

Voici une liste exhaustive des verbes http: http://annevankesteren.nl/2007/10/http-methods

Là, le correctif HTTP de la RFC officielle: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

La méthode PATCH demande qu'un ensemble de changements décrits dans l'entité de demande soit appliqué à la ressource identifiée par l'URI de demande. L'ensemble des modifications est représenté dans un format appelé «document de patch» identifié par un type de support. Si Request-URI ne pointe pas vers une ressource existante, le serveur PEUT créer une nouvelle ressource, en fonction du type de document de correctif (s'il peut logiquement modifier une ressource nulle) et des autorisations, etc.

La différence entre les demandes PUT et PATCH se reflète dans la manière dont le serveur traite l'entité incluse pour modifier la ressource identifiée par l'URI de demande. Dans une demande PUT , l'entité incluse est considérée comme une version modifiée de la ressource stockée sur le serveur d'origine, et le client demande que la version stockée soit remplacée. Avec PATCH , cependant, l'entité incluse contient un ensemble d'instructions décrivant comment une ressource résidant actuellement sur le serveur d'origine doit être modifiée pour produire une nouvelle version. La méthode PATCH affecte la ressource identifiée par Request-URI , et elle PEUT également avoir des effets secondaires sur d'autres ressources; c'est-à-dire que de nouvelles ressources peuvent être créées, ou des ressources existantes modifiées, par l'application d'un PATCH .

Autant que je sache, le verbe PATCH n'est pas utilisé tel qu'il est dans les applications rails ... Si je comprends bien, le verbe correctif RFC devrait être utilisé pour envoyer des instructions de correctif comme lorsque vous effectuez une différence entre deux fichiers. Au lieu d'envoyer à nouveau l'entité entière, vous envoyez un correctif qui pourrait être beaucoup plus petit que de renvoyer l'entité entière.

Imaginez que vous vouliez éditer un gros fichier. Vous modifiez 3 lignes. Au lieu de renvoyer le fichier, il vous suffit d'envoyer le diff. Du côté positif, l'envoi d'une demande de correctif pourrait être utilisé pour fusionner des fichiers de manière asynchrone. Un système de contrôle de version pourrait potentiellement utiliser le verbe PATCH pour mettre à jour le code à distance.

Un autre cas d'utilisation possible est quelque peu lié aux bases de données NoSQL, il est possible de stocker des documents. Supposons que nous utilisions une structure JSON pour envoyer des données entre le serveur et le client. Si nous voulions supprimer un champ, nous pourrions utiliser une syntaxe similaire à celle de mongodb pour $ unset . En fait, la méthode utilisée dans mongodb pour mettre à jour des documents pourrait probablement être utilisée pour gérer les correctifs json.

Prenant cet exemple:

db.products.update(
   { sku: "unknown" },
   { $unset: { quantity: "", instock: "" } }
)

Nous pourrions avoir quelque chose comme ça:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

Dernier point, mais non le moindre, les gens peuvent dire ce qu'ils veulent sur les verbes HTTP. Il n'y a qu'une seule vérité, et la vérité est dans les RFC.


1
Il est important de noter que la RFC 5789 est toujours en phase de proposition et n'a pas été officiellement acceptée et est actuellement signalée comme «irrata exist». Cette «meilleure pratique» est très discutée et techniquement, PATCH ne fait pas encore partie du standard HTTP. La seule vérité ici est que puisque la RFC n'est pas acceptée, vous ne devriez pas le faire.
fishpen0

3
Même s'il est toujours proposé, cela ne signifie pas qu'il ne devrait pas être utilisé. Si c'était le cas, nous ne pourrions pas utiliser des websockets et de nombreux autres rfcs qui sont encore en proposition ... Implémenter la proposition est 100 fois mieux que d'implémenter quelque chose de complètement personnalisé que personne d'autre n'implémente.
Loïc Faure-Lacroix

BS. Ce n'est pas "dans la proposition", et cela fait partie de la norme HTTP (la norme, RFC 7231 délègue à un registre IANA pour les méthodes, et PATCH y est répertorié).
Julian Reschke

@JulianReschke si vous lisez la deuxième ligne de cette RFC, vous verrez qu'elle est toujours marquée comme PROPOSED STANDARD . Donc non, la méthode patch est toujours en proposition. Le rfc est ici btw. tools.ietf.org/html/rfc5789 et le rfc7231 est également PROPOSÉ NORME . Si vous regardez la RFC821 par exemple, elle est marquée INTERNET STANDARD
Loïc Faure-Lacroix

1
@JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... Ce n'est pas ma parole. Une norme proposée ne signifie pas que vous ne pouvez pas la mettre en œuvre correctement, comme je l'ai expliqué ci-dessus. Cela ne signifie pas qu'il n'est pas assez stable pour être mis en œuvre ... mais il est toujours proposé à moins qu'il ne soit marqué comme Internet Standard ... Je ne sais pas comment vous discutez à ce sujet. C'est ce qu'on appelle «norme proposée», cela ne peut pas signifier autre chose qu'une proposition. Si vous voulez faire valoir qu'une proposition de norme peut être utilisée. C'est exactement ce que j'ai écrit.
Loïc Faure-Lacroix

104

J'ai passé quelques heures avec Google et j'ai trouvé la réponse ici

PUT => Si l'utilisateur peut mettre à jour tout ou juste une partie de l'enregistrement , utilisez PUT (l'utilisateur contrôle ce qui est mis à jour)

PUT /users/123/email
new.email@example.org

PATCH => Si l'utilisateur ne peut mettre à jour qu'un enregistrement partiel , disons simplement une adresse e-mail (l'application contrôle ce qui peut être mis à jour), utilisez PATCH.

PATCH /users/123
[description of changes]

Pourquoi Patch

PUTLa méthode nécessite plus de bande passante ou gère des ressources complètes à la place sur partielle. Ainsi a PATCHété introduit pour réduire la bande passante.

Explication sur PATCH

PATCH est une méthode qui n'est ni sûre, ni idempotente, et permet des mises à jour complètes et partielles et des effets secondaires sur d'autres ressources.

PATCH est une méthode dont l'entité incluse contient un ensemble d'instructions décrivant comment une ressource résidant actuellement sur le serveur d'origine doit être modifiée pour produire une nouvelle version.

PATCH /users/123
[
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }
]

Ici plus d'informations sur put et patch


7
Pourquoi ce PATCH n'est-il pas sûr?
Bishisht Bhatta

1
PATCHparmi POST, PUTetc. n'est pas «sûr», car il modifie vos données (a des effets secondaires). Comparé à GET, OPTIONSetc. (méthodes sûres) où vous pouvez appeler les points de terminaison plusieurs fois sans aucun effet secondaire.
emix

1
PATCH n'a PAS été introduit pour économiser uniquement la bande passante. Comme le stipule la RFC 5789:> "Une nouvelle méthode est nécessaire pour améliorer l'interopérabilité et éviter les erreurs." Dans un environnement multi-parallèle, le fait de n'avoir que des PUT qui incluent le reste de la charge utile augmenterait le risque de modification d'autres attributs de la ressource. PATCH résout ce problème.
Tomasz Nazar

43

mettre
si je veux changer mon firstnom , puis envoyer mettre demande de mise à jour

{ "first": "Nazmul", "last": "hasan" } 

mais ici, il y a un problème est putque lorsque je veux envoyer une putdemande, je dois envoyer les deux paramètres qui sont firstet last
il est donc obligatoire d'envoyer à nouveau toute la valeur

patch :
patchdemande dit. n'envoyez dataque celui que vous voulez updateet cela n'affectera ni ne modifiera les autres données.
donc pas besoin d'envoyer à nouveau toute la valeur. juste je veux mettre à jour mon prénom donc je dois envoyer seulement le firstnom pour mettre à jour.


13

Voici la différence entre les méthodes POST, PUT et PATCH d'un protocole HTTP.

PUBLIER

Une méthode HTTP.POST crée toujours une nouvelle ressource sur le serveur. C'est une demande non idempotente, c'est-à-dire que si l'utilisateur rencontre les mêmes demandes 2 fois, il créerait une autre nouvelle ressource s'il n'y a pas de contrainte.

La méthode de publication http est comme une requête INSERT dans SQL qui crée toujours un nouvel enregistrement dans la base de données.

Exemple: Utilisez la méthode POST pour enregistrer un nouvel utilisateur, une commande, etc. où le serveur principal décide de l'ID de ressource pour la nouvelle ressource.

METTRE

Dans la méthode HTTP.PUT, la ressource est d'abord identifiée à partir de l'URL et si elle existe, elle est mise à jour, sinon une nouvelle ressource est créée. Lorsque la ressource cible existe, elle remplace cette ressource par un nouveau corps complet. C'est la méthode HTTP.PUT est utilisée pour CRÉER ou METTRE À JOUR une ressource.

La méthode http put est comme une requête MERGE dans SQL qui insère ou met à jour un enregistrement selon que l'enregistrement donné existe.

La requête PUT est idempotente, c'est-à-dire que frapper deux fois les mêmes requêtes mettrait à jour l'enregistrement existant (aucun nouvel enregistrement créé). Dans la méthode PUT, l'ID de la ressource est décidé par le client et fourni dans l'url de la demande.

Exemple: utilisez la méthode PUT pour mettre à jour l'utilisateur ou la commande existant.

PIÈCE

Une méthode HTTP.PATCH est utilisée pour les modifications partielles d'une ressource, c'est-à-dire les mises à jour delta.

La méthode de correctif http est comme une requête UPDATE dans SQL qui définit ou met à jour les colonnes sélectionnées uniquement et non la ligne entière.

Exemple: vous pouvez utiliser la méthode PATCH pour mettre à jour le statut de la commande.

PATCH / api / users / 40450236 / commande / 10234557

Corps de la demande: {status: 'Delivered'}


C'est la pire explication que l'on puisse lire sur les put et les patchs. Et d'ailleurs, après tant de bonnes réponses déjà postées, qu'est-ce qui vous fait penser que votre réponse est différente ici?
CodeHunter du

3

Il existe des limitations dans PUT over PATCH lors des mises à jour. L'utilisation de PUT nous oblige à spécifier tous les attributs même si nous ne voulons changer qu'un seul attribut. Mais si nous utilisons la méthode PATCH, nous ne pouvons mettre à jour que les champs dont nous avons besoin et il n'est pas nécessaire de mentionner tous les champs. PATCH ne nous permet pas de modifier une valeur dans un tableau, ni de supprimer un attribut ou une entrée de tableau.


1

PUT et PATCH méthodes sont de nature similaire, mais il existe une différence essentielle.

PUT - dans PUT demande , l'entité incluse serait considérée comme la version modifiée d'une ressource résidant sur le serveur et elle serait remplacée par cette entité modifiée.

PATCH - dans la demande PATCH , l'entité incluse contient l'ensemble d'instructions indiquant comment l'entité résidant sur le serveur serait modifiée pour produire une version plus récente.


1

Selon les termes HTTP, la PUTrequête ressemble à une instruction de mise à jour de base de données. PUT- est utilisé pour modifier la ressource existante (précédemment POSTED). D'autre part, la PATCHdemande est utilisée pour mettre à jour une partie de la ressource existante.

Par exemple:

Détails du client:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";
//..

Quand nous voulons mettre à jour l'enregistrement entier? nous devons utiliser Http PUT verbpour cela.

tel que:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";
//..

D'autre part, si nous voulons mettre à jour uniquement la partie de l'enregistrement et non l'intégralité de l'enregistrement, optez pour Http PATCH verb. tel que:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";
   //..

PUT VS POST:

Lors de l'utilisation de la PUTdemande, nous devons envoyer tous les paramètres tels que firstName, lastName, email, phoneNumber Where as In patchrequest uniquement envoyer les paramètres que nous voulons mettre à jour et cela n'affectera ni ne modifiera les autres données.

Pour plus de détails, veuillez visiter: https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


0

Les méthodes Put et Patch sont similaires. Mais dans les rails, il a une méthode différente. Si nous voulons mettre à jour / remplacer tout l'enregistrement, nous devons utiliser la méthode Put. Si nous voulons mettre à jour un enregistrement particulier, utilisez la méthode Patch.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.