Quelle est l'utilité des méthodes de requête HTTP PUT et DELETE ?

Question

Je n'ai jamais utilisé les méthodes de requête HTTP PUT ou DELETE. J'ai tendance à utiliser GET lorsque l'état du système (mon application ou mon site web) n'est pas affecté (comme une liste de produits) et à utiliser POST lorsqu'il l'est (comme passer une commande). Ces deux méthodes ne sont-elles pas toujours suffisantes, ou est-ce que quelque chose m'échappe ?

Answer 1

DELETE sert à supprimer la ressource demandée :

La méthode DELETE demande au serveur d'origine de supprimer la ressource identifiée par la Request-URI. Cette méthode PEUT être remplacée par une intervention humaine (ou d'autres moyens) sur le serveur d'origine. Le client ne peut pas être assuré que l'opération a été exécutée, même si le code d'état renvoyé par le serveur d'origine indique que l'action a été menée à bien

PUT sert à mettre ou à mettre à jour une ressource sur le serveur :

La méthode PUT demande que l'entité jointe soit stockée sous l'URL de la demande fournie. Si la Request-URI fait référence à une ressource déjà existante, l'entité jointe devrait être considérée comme une version modifiée de celle qui réside sur le serveur d'origine. Si la Request-URI ne renvoie pas à une ressource existante, et que l'URI peut être défini comme une nouvelle ressource par l'agent utilisateur demandeur, le serveur d'origine peut créer la ressource avec cette URI

Pour les spécifications complètes, visitez le site :

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Comme les navigateurs actuels ne supportent malheureusement pas d'autres verbes que POST et GET dans les formulaires HTML En général, il n'est pas possible d'utiliser pleinement le protocole HTTP avec eux (vous pouvez néanmoins détourner leur soumission via JavaScript). L'absence de support pour ces méthodes dans les formulaires HTML a conduit à des URI contenant des verbes, comme par exemple

POST http://example.com/order/1/delete

ou pire encore

POST http://example.com/deleteOrder/id/1

en tunnelisant efficacement la sémantique CRUD sur HTTP. Mais les verbes n'ont jamais été censés faire partie de l'URI. Au contraire, HTTP fournit déjà le mécanisme et la sémantique permettant de CRUDer une ressource (par exemple, une commande) par le biais des méthodes HTTP. HTTP est un protocole et pas seulement un service de tunnelisation des données.

Ainsi, pour supprimer une ressource sur le serveur Web, il faut appeler

DELETE http://example.com/order/1

et pour le mettre à jour, il faut appeler

PUT http://example.com/order/1

et fournir la représentation de la ressource mise à jour dans le corps du PUT pour que le serveur web l'applique ensuite.

Donc, si vous construisez une sorte de client pour un API REST vous lui ferez probablement envoyer des demandes PUT et DELETE. Il peut s'agir d'un client intégré au navigateur, par exemple qui envoie des requêtes via JavaScript, ou d'un outil fonctionnant sur un serveur, etc.

Pour plus de détails, visitez le site :

• http://martinfowler.com/articles/richardsonMaturityModel.html
• Les méthodes PUT, DELETE, HEAD, etc. sont-elles disponibles dans la plupart des navigateurs web ?
• Pourquoi n'y a-t-il pas de méthodes PUT et DELETE dans les formulaires HTML ?
• Faut-il utiliser PUT et DELETE dans les formulaires ?
• http://amundsen.com/examples/put-delete-forms/
• http://www.quora.com/HTTP/Why-are-PUT-and-DELETE-no-longer-supported-in-HTML5-forms

Answer 2

L'utilisation des verbes de requête HTTP tels que GET, POST, DELETE, PUT etc... vous permet de construire des applications web RESTful. Lisez à ce sujet ici : http://en.wikipedia.org/wiki/Representational_state_transfer

La façon la plus simple d'en voir les avantages est de regarder cet exemple. Chaque framework MVC possède un Router/Dispatcher qui fait correspondre les URL aux contrôleurs d'action. Donc une URL comme celle-ci : /blog/article/1 invoquerait blogController::articleAction($id); Maintenant, ce routeur est seulement conscient de l'URL ou /blog/article/1/

Mais si ce routeur avait connaissance de l'ensemble de l'objet de la requête HTTP au lieu de la seule URL, il pourrait avoir accès aux verbes de la requête HTTP (GET, POST, PUT, DELETE...), et à bien d'autres choses utiles sur la requête HTTP en cours.

Cela vous permettrait de configurer l'application de manière à ce qu'elle puisse accepter la même URL et l'affecter à différents contrôleurs d'action en fonction du verbe de la requête HTTP.

Par exemple :

si vous voulez reprendre l'article 1, vous pouvez le faire :

GET /blog/article/1 HTTP/1.1

mais si vous voulez supprimer l'article 1 vous ferez ceci :

DELETE /blog/article/1 HTTP/1.1

Remarquez que les deux requêtes HTTP ont le même URI, /blog/article/1, la seule différence est le verbe de la requête HTTP. En fonction de ce verbe, votre routeur peut appeler différents ActionController. Cela vous permet de construire des URL soignées.

Lisez ces deux articles, ils pourraient vous aider :

Symfony 2 - Principes fondamentaux de HTTP

Symfony 2 - Routage

Ces articles concernent le framework Symfony 2, mais ils peuvent vous aider à comprendre comment fonctionnent les requêtes et les réponses HTTP.

J'espère que cela vous aidera !

Answer 3

Bien que je prenne le risque de ne pas être populaire, je dis que ils ne sont pas utiles de nos jours .

Je pense qu'ils étaient bien intentionnés et utiles dans le passé, lorsque par exemple DELETE demandait au serveur de supprimer la ressource trouvée à l'URL fournie et que PUT (avec son frère PATCH) demandait au serveur d'effectuer une mise à jour de manière idempotente.

Les choses ont évolué et les URL sont devenues virtuelles (voir réécriture de l'URL par exemple) faisant perdre aux ressources leur signification initiale de dossier/sous-fichier/fichier réel et ainsi, les verbes d'action CRUD couverts par les méthodes du protocole HTTP (GET, POST, PUT/PATCH, DELETE) ont perdu leur trace.

Prenons un exemple :

• /api/entity/list/{id} vs GET /api/entity/{id}
• /api/entity/add/{id} vs POST /api/entité
• /api/entité/edit/{id} vs PUT /api/entity/{id}
• /api/entity/delete/{id} vs DELETE /api/entity/{id}

Dans la partie gauche, la méthode HTTP n'est pas indiquée, car elle n'a pas d'importance (POST et GET suffisent). Dans la partie droite, les méthodes HTTP appropriées sont utilisées.

Le côté droit est élégant, propre et professionnel. Imaginez maintenant que vous devez maintenir un code qui a utilisé l'API élégante et que vous devez rechercher où l'appel de suppression est effectué. Vous allez chercher "api/entité" et parmi les résultats, vous devrez voir lequel fait DELETE. Ou pire encore, vous avez un programmeur junior qui, par erreur, a remplacé PUT par DELETE et comme l'URL est la même merde s'est produite.

À mon avis, placer le verbe d'action dans l'URL présente des avantages par rapport à l'utilisation de la méthode HTTP appropriée pour cette action, même si ce n'est pas très élégant. Si vous voulez voir où l'appel de suppression est effectué, il vous suffit de rechercher "api/entity/delete" et vous le trouverez tout de suite.

Construire une API sans toute la panoplie de méthodes HTTP permet de la consommer et de la maintenir plus facilement par la suite.

Answer 4

Méthodes sûres : Obtenir la ressource/aucune modification de la ressource
Idempotent : Aucun changement dans le statut des ressources si elles sont demandées plusieurs fois
Méthodes non sécurisées : Créer ou mettre à jour une ressource/modification dans une ressource
Non-empotent : Changement de statut des ressources en cas de demandes répétées

Selon vos besoins :

1) Pour une opération sûre et idempotente (Fetch Resource), utilisez ---------. MÉTHODE GET
2) Pour les opérations non sécurisées et non autonomes (insertion de ressources), utiliser---------. MÉTHODE POST
3) Pour une opération non sécurisée et idempotente (mise à jour de la ressource), utilisez---------. MÉTHODE PUT
3) Pour une opération non sécurisée et idempotente (Supprimer une ressource), utiliser---------. MÉTHODE DE SUPPRESSION

Answer 5

Voir la réponse acceptée de @Gordon, le point clé étant simplement ceci :

PUT et DELETE sont des verbes spécifiques ayant une signification, qui donnent des instructions au serveur pour faire quelque chose de spécifique et comment l'instruction doit être traitée.

Les normes et la sémantique, c'est bien, mais quelle est l'utilité réelle de DELETE si tout ce que je veux faire, c'est exécuter un code pour supprimer quelque chose d'une base de données ?

Et si nous disions : "OK, mais il est plus facile pour moi de faire une suppression en envoyant un GET à mon URI avec un chemin d'accès /api/entity/delete/{id} (comme suggéré dans la réponse de @Bogdan). OK, regardons la définition de GET :

La méthode GET permet de récupérer n'importe quelle information (sous la forme d'une entité) identifiée par l'url de la demande.

Source - Normes du W3C - https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Si vous utilisez GET pour un DELETE vous êtes une utilisation manifestement erronée de la méthode selon sa définition standard.

D'accord, disons encore "OK mais cela n'a pas vraiment d'importance parce qu'il est juste plus pratique pour un développeur de lire une URI quelque part qui utilise une méthode GET et qui dit /api/entity/delete/{id} au lieu d'avoir une méthode DELETE qui supprime les ressources ayant la même signature qu'une méthode GET qui récupère, afin que le développeur comprenne que c'est destiné à la suppression. Considérons une signature de méthode DELETE bien structurée (l'exemple est pour .NET Core 5) :

// DELETE: api/TodoItems/5
[HttpDelete("{id}")]
public async Task<IActionResult> DeleteTodoItem(long id)
{

Il ne répondra pas à une requête get, (ainsi, par exemple, la suppression accidentelle au lieu de la récupération lors d'un appel à l'API est plus protégée - le développeur doit explicitement effectuer une demande DELETE à l'API). De plus, nous disposons d'une opération d'API très claire, bien structurée et nommée, qui est facile à découvrir par un développeur ou même par un outil automatisé (par exemple, un développeur peut maintenant rechercher spécifiquement toute occurrence de DELETE dans le code, ou pour le nom de la méthode qui indique clairement le DELETE). De plus, ce modèle est conforme à une norme généralement acceptée pour une API "RESTFUL", à savoir que devrait rendre l'API plus largement reconnaissable et interprétable par les développeurs (et potentiellement par tout outil automatisé).

OK, c'est bien, mais quelle est la différence réelle en faisant un DELETE ? Pourquoi même utiliser DELETE au lieu de GET ? Mon opération consiste à supprimer quelque chose de la base de données, pourquoi mon serveur web devrait-il s'en soucier ? OK, réfléchissons à la définition de DELETE :

9.7 DELETE - La méthode DELETE demande au serveur d'origine de supprimer la ressource identifiée par la Request-URI. Cette méthode PEUT être être remplacée par une intervention humaine (ou autre) sur le serveur d'origine. d'origine.

Donc maintenant, si nous spécifions une suppression, nous avons le potentiel pour comportement spécifique sur le serveur qui permet potentiellement d'annuler une action de suppression par une intervention manuelle ou automatique. Dans un cas d'utilisation particulier, cela pourrait être important.

OK, DELETE fonctionne pour moi alors, mais pourquoi utiliser PUT ? Par exemple, il est plus pratique de créer une méthode "upsert" qui utilise POST et met à jour la ressource si elle existe ou la crée si elle n'existe pas.

Personnellement, je le fais généralement lorsque j'implémente une API qui effectue des opérations sur une base de données, même si, là encore, il y a une signification spécifique à PUT, à savoir qu'elle indique spécifiquement la mise à jour d'une ressource, tandis que POST indique la création L'utilisation de POST pour la création et la mise à jour est donc contraire à la norme. Pour ma part, je pense qu'une API REST est un cas où je considère généralement que l'aspect pratique de la fonctionnalité upsert est plus important que l'utilisation stricte du verbe correct pour ajouter ou insérer, mais je pourrais manquer quelque chose ici.

L'utilisation de PUT en dehors d'une api REST pourrait être plus significative à des fins pratiques, par exemple si nous effectuons une opération de mise à jour où le serveur peut potentiellement effacer tout cache en comprenant que la ressource a été mise à jour (ce qui est plus significatif si notre ressource est un document entier, par exemple). Il peut y avoir des avantages pratiques que je n'ai pas envisagés lorsque PUT est utilisé dans une API reposante pour une opération de mise à jour.

La définition standard de POST stipule qu'une réponse POST réussie DOIT être 201 (créée), et pas seulement le générique "200 OK", afin que nous puissions interpréter correctement que la création de la ressource est explicitement réussie. Cette réponse n'est pas appropriée pour une opération de mise à jour, mais il n'y a pas de "DOIT" spécifié dans la norme pour le code de réponse. Il est certainement courant pour les développeurs d'utiliser POST pour un upsert et de renvoyer 200 (OK) en cas de succès, qu'il s'agisse d'une création ou d'une mise à jour.

La norme pour PUT est plus stricte et spécifie que toute création inattendue d'une ressource lors d'une tentative de mise à jour DOIT être indiquée par un code de réponse 201. Cela peut se produire si aucune ressource existante n'existe à l'URI spécifié. La norme explique que si nous utilisons PUT, nous obtenons un retour d'information plus clair sur le résultat de notre tentative de mise à jour.

De la norme du W3C :

[si un put] ne pointe pas vers une ressource existante, et que l'URI est capable d'être défini comme une nouvelle ressource par l'agent utilisateur demandeur, le demandeur, le serveur d'origine peut créer la ressource avec cet URI. Si une nouvelle ressource est créée, le serveur d'origine DOIT en informer l'agent utilisateur via la réponse 201 (Created). Si une ressource existante est modifiée, les codes de réponse 200 (OK) ou 204 (No Content) DOIVENT être envoyés pour indiquer que la demande a abouti.