Comment soutenir Partielle des Mises à jour (PATCH) dans le RESTE de

Je veux mettre en œuvre les mises à jour partielles pour ma ressource que j'ai de grandes ressources et souhaitez mettre à jour les informations partielles à partir d'elle.Je suis allé à travers les liens suivants, mais pas

en mesure de déterminer si l'utilisation de HTTP POST ou PATCH méthodes.

Merci de proposer toute solution valable pour cela.

u got toute solution

InformationsquelleAutor prashant | 2011-11-15

92

Selon RFC5789 (http://tools.ietf.org/html/rfc5789), c'est précisément ce PATCH est pour:

Plusieurs applications s'étendant le Protocole de Transfert Hypertexte (HTTP)
besoin d'une fonction pour effectuer partielle des ressources de la modification. L'existant
Méthode HTTP PUT seulement permet un remplacement complet d'un document.
Cette proposition ajoute une nouvelle méthode HTTP, un PATCH pour modifier une existante
HTTP ressource.

La distinction entre le PATCH et la METTRE décrit comme:

La différence entre les MISES et les demandes de correctifs est reflété dans le
façon par le serveur de l'entité incluse pour modifier la ressource
identifié par l'URI de Demande. Dans une demande, l'entité incluse
est considéré comme une version modifiée de la ressource stockée sur le
serveur d'origine, et que le client demande à ce que le numéro de version
être remplacé. Avec le PATCH, cependant, l'entité incluse contient un ensemble
des instructions décrivant comment une ressource résidant sur le
serveur d'origine devrait être modifié afin de produire une nouvelle version.

Les limites de la POSTE sont également décrits:

La méthode PUT est déjà défini pour remplacer une ressource
avec un nouveau corps, et ne peuvent pas être réutilisées à des modifications partielles.
Sinon, les procurations et les caches, et même les clients et les serveurs, peut-être
confus quant à la suite de l'opération. POST est déjà utilisé, mais
sans une large interopérabilité (pour l'un, il n'y a pas de méthode standard pour
découvrez format de patch de soutien) [...]

Je vous suggère de lire les RFC et faire votre propre avis, mais pour moi, cela semble assez clair de la coupe des demandes de correctifs doivent être traitées comme des mises à jour partielles. (NB: ils ne sont PAS idempotent, contrairement à la METTRE.)

EDIT: comme l'a souligné Eugene, dans les commentaires, bien que les demandes de correctifs sont "neither safe nor idempotent as defined by [RFC2616]", ils peuvent être formulées ainsi:

Un PATCH demande peut être émis de manière à être idempotent,
ce qui permet également d'éviter de mauvais résultats lors des collisions entre les deux
Demandes de correctifs sur la même ressource dans un même laps de temps.
Les Collisions à partir de plusieurs demandes de correctifs peuvent être plus dangereux que
METTRE les collisions parce que certains patch formats besoin pour fonctionner à partir d'un
connu de la base de points ou sinon ils vont corrompre la ressource. Les Clients
l'utilisation de ce genre de patch application DOIT utiliser une requête conditionnelle
tels que la demande échoue si la ressource a été mise à jour
depuis le client de dernier accès à la ressource. Par exemple, le client
pouvez utiliser une forte ETag [RFC2616] dans une Si-Match de l'en-tête sur le PATCH
demande.
- +1 j'ajouterai que PATCH peut être faite quantité en incluant les If-Match en-tête, comme décrit dans la RFC vous faites allusion. Effectivement, il est fortement suggéré dans le RFC pour le faire, comme l'application des correctifs de la version incorrecte peut bousiller une référence, contrairement à un qui remplace simplement la chose entière.
- Vrai - si, pour obtenir ce tous de travail, vous devez également être génératrice de / en utilisant les ETags correctement.
- Ce qui est une bonne idée dans de nombreux cas, de toute façon, disons pour la mise en cache, mais en particulier pour faire des mises à jour partielles, où vous avez le plus souvent voulez vous assurer que vous êtes patcher une version spécifique de la ressource. Il suffit parfois d'informations de contexte peuvent être incorporées dans le diff, mais ETags sont un diff-format moyen indépendant de ce qui est souvent facile à intégrer dans l'usage général des cadres qui ne connaissent rien en particulier diff formats.
- Ce doit être marqué comme réponse correcte
- Notez également que le PATCH RFC dit: "[en PATCH,] l'entité incluse contient un instructions décrivant comment une ressource [...] devrait être modifié.". Json-patch ou xml-patch sont de bons candidats pour les types de médias pour être utilisé le long avec le PATCH de la méthode.
InformationsquelleAutor Hugo Rodger-Brown

Vous devez utiliser la méthode de PATCH comme décrit dans la RFC-7386 "json fusion PATCH".

E. g. si vous voulez changer la valeur de "a" et la suppression de "f" dans les ressources comme:

   {
     "a": "b",
     "c": {
       "d": "e",
       "f": "g"
     }
   }

Vous pouvez obtenir ce par l'envoi d':

       PATCH /target HTTP/1.1
       Host: example.org
       Content-Type: application/merge-patch+json

       {
         "a":"z",
         "c": {
           "f": null
         }
       }

InformationsquelleAutor TechnoPriest

-16

PATCH est à utiliser avec un format de patch, de niveau document correctifs uniquement (aka un diff sur la représentation réelle). Son utilisation à d'autres fins est douteuse et contestable, et il n'est pas clair que la méthode a été conçu pour les non-media-type utilise.

En général, un POSTE sera la bonne approche, mais vous pouvez scinder votre ressource en de multiples ressources au lieu et à modifier celles à la place.

[Édité pour plus de clarté, que certains ne lisent pas les commentaires]
- Je ne vois pas comment prashanth exigences: partial updates for my resource serait en conflit avec ce PATCH est censé faire: entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. C'est à partir de rfc5789, mais les plus âgés de rfc2068 est similaire. Également en ce qui concerne la diff on the actual bytes, vous n'êtes pas, éventuellement, de se cette confondu avec HTTP plages où les réalisateurs sont seulement tenus de mettre en œuvre des plages d'octet (mais cela peut être étendu à d'autres unités)?
- Je ne pas confondre http demandes de plage avec le patch documents, non, merci de préciser la source de confusion pour les lecteurs. La spécification en question est assez clair sur un patch document un document qui modifie l'état d'une ressource, de moins en moins claires sur la manière de présenter un tel document, en laissant le choix à vous. À partir d'une spécification de point de vue, il est encouragé à le faire conditionnelles, et fort etags sont donnés en exemple, qui nous le savons, sont une représentation spécifique. Connus ou publié diff formats que vous souhaitez utiliser en Reste) sont spécifiques au document, d'où ma réponse.
- En général, une requête POST est utilisé pour la création de ressources, de ne pas les mettre à jour.
- Roy Fielding n'est pas d'accord avec vous. roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
InformationsquelleAutor SerialSeb

Vous devez vous connecter pour publier un commentaire.