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.