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

J'ai lu beaucoup de choses à ce sujet mais je n'ai pas pu tirer de conclusion sur ce sujet.

Mais je n'ai jamais utilisé les méthodes de requête HTTP PUT ou DELETE. Ma tendance est d'utiliser GET lorsque l'état du système (mon application ou mon site Web) peut ne pas être affecté (comme la liste des produits) et d'utiliser POST lorsqu'il est affecté (commande passée). N'est-ce pas suffisant ou est-ce que je manque quelque chose?

DELETE sert à supprimer la ressource de demande:

La méthode DELETE demande que le serveur d'origine supprime la ressource identifiée par 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 garanti que l’opération a été effectuée, même si le code d’état renvoyé par le serveur d’origine indique que l’action s’est terminée avec succès…

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

La méthode PUT demande que l'entité incluse soit stockée sous l'URI de demande fourni. Si le Request-URI se réfère à une ressource déjà existante, l'entité incluse DEVRAIT être considérée comme une version modifiée de celle résidant sur le serveur d'origine. Si l'URI de demande ne pointe pas vers une ressource existante et que cet URI peut être défini comme une nouvelle ressource par l'agent utilisateur demandeur, le serveur d'origine peut créer la ressource avec cet URI…

Pour consulter les spécifications complètes, visitez:

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

Étant donné que les navigateurs actuels ne prennent malheureusement pas en charge d'autres verbes que POST et GET dans les formulaires HTML , vous ne pouvez généralement pas utiliser HTTP dans toute sa mesure avec eux (vous pouvez toujours détourner leur soumission via JavaScript). L'absence de prise en charge de 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

tunneliser efficacement la sémantique CRUD sur HTTP. Mais les verbes n'ont jamais été censés faire partie de l'URI. Au lieu de cela, HTTP fournit déjà le mécanisme et la sémantique à CRUD une ressource (par exemple une commande) via les méthodes HTTP. HTTP est un protocole et pas seulement un service de tunneling de données.

Donc, pour supprimer une ressource sur le serveur Web, vous appelez

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

et pour le mettre à jour, vous appelleriez

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

et fournissez la représentation de ressource mise à jour dans le corps PUT pour que le serveur Web s'applique ensuite.

Donc, si vous créez une sorte de client pour une API REST , vous lui demanderez probablement d'envoyer des requêtes PUT et DELETE. Cela pourrait être un client intégré à un navigateur, par exemple l'envoi de requêtes via JavaScript ou un outil fonctionnant sur un serveur, etc.

Pour plus de détails, visitez:

• 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

L'utilisation du verbe HTTP Request tel que GET, POST, DELETE, PUT etc ... vous permet de créer des applications Web RESTful. Lisez à ce sujet ici: http://en.wikipedia.org/wiki/Representational_state_transfer

Le moyen le plus simple d'en voir les avantages est de regarder cet exemple. Chaque framework MVC a un Router/Dispatcherqui mappe les URL aux actionControllers. Donc une URL comme celle-ci: /blog/article/1invoquerait blogController::articleAction($id); Maintenant, ce routeur ne connaît que l'URL ou/blog/article/1/

Mais si ce routeur était conscient de tout l'objet de requête HTTP au lieu de simplement URL, il pourrait avoir accès au verbe de requête HTTP (GET, POST, PUT, DELETE ...), et bien d'autres choses utiles sur la requête HTTP actuelle.

Cela vous permettrait de configurer l'application afin qu'elle puisse accepter la même URL et la mapper à différents actionControllers en fonction du verbe HTTP Request.

Par exemple:

si vous souhaitez récupérer l'article 1, vous pouvez le faire:

GET /blog/article/1 HTTP/1.1

mais si vous souhaitez supprimer l'article 1, vous le ferez:

DELETE /blog/article/1 HTTP/1.1

Notez que les deux requêtes HTTP ont le même URI, / blog / article / 1, la seule différence est le verbe de requête HTTP. Et sur la base de ce verbe, votre routeur peut appeler différents actionController. Cela vous permet de créer des URL soignées.

Lisez ces deux articles, ils pourraient vous aider:

Symfony 2 - Fondamentaux HTTP

Symfony 2 - Routage

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

J'espère que cela t'aides!

Méthodes sûres: Obtenir la ressource / Aucune modification dans la ressource
Idempotent: Aucun changement dans l'état de la ressource si demandé plusieurs fois
Méthodes non sûres: Créer ou mettre à jour une ressource / Modification dans la ressource
Non idempotent: Changement dans l'état de la ressource si demandé plusieurs fois

Selon votre condition:

1) Pour un fonctionnement sûr et idempotent (Fetch Resource), utilisez --------- GET METHOD
2) Pour un fonctionnement non sûr et non idempotent (Insert Resource), utilisez --------- POST METHOD
3) Pour une opération non sécurisée et idempotente (Update Resource), utilisez --------- PUT METHOD
3) Pour une opération non sûre et idempotente (Delete Resource), utilisez --------- DELETE METHOD

Bien que je prenne le risque de ne pas être populaire, je dis qu'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 a dit au serveur de supprimer la ressource trouvée à l'URL fournie et PUT (avec son frère PATCH) a dit au serveur de faire la mise à jour de manière idempotente.

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

Prenons un exemple:

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

Sur le côté gauche n'est pas écrite la méthode HTTP, essentiellement peu importe (POST et GET suffisent) et sur le côté droit des 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 utilise l'API élégante et que vous devez rechercher où l'appel de suppression est effectué. Vous recherchez "api / entité" et parmi les résultats, vous devrez voir lequel est en train de supprimer. Ou pire encore, vous avez un programmeur junior qui par erreur a basculé PUT avec DELETE et comme URL, c'est la même merde qui s'est produite.

À mon avis, mettre 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 si élégant. Si vous voulez voir où supprimer l'appel est effectué, il vous suffit de rechercher "api / entity / delete" et vous le trouverez immédiatement.

Construire une API sans l'ensemble des méthodes HTTP facilite sa consommation et sa maintenance par la suite