Quelle est la différence entre les méthodes HTTP GET, POST, PUT et DELETE

Je développe le service REST WCF et, théoriquement, je sais quand opter pour quel but.

  • GET pour obtenir la ressource
  • PUT à jour
  • POST à insérer
  • DELETE pour supprimer

Mais quel est l’inconvénient si nous ne suivons pas cette règle ci-dessus, supposons d’insérer un enregistrement que j’ai utilisé la méthode GET ?

Étant donné que la méthode HTTP GET est spécifiée comme idempotent, une demande GET, par spécification, peut être renvoyée en supposant qu’elle ne changera rien sur le serveur. Ce n’est pas le cas pour un HTTP POST qui, par spécification, peut modifier le statut de l’application exécutée sur le serveur.

Ainsi, par spécification, on peut effectuer un HTTP GET contre un nombre de pages N sans craindre de changer de statut.

Ne pas respecter la spécification peut avoir divers résultats indésirables. Par exemple, les robots d’indexation Web suivent la requête GET pour indexer un site, mais pas POST. Si vous avez autorisé une requête HTTP GET à apporter des modifications à la firebase database, vous pouvez facilement comprendre l’implication indésirable qu’elle peut avoir.

Respecter une spécification revient à respecter un accord entre votre service ou votre site Web et un ensemble de consommateurs différents, qui peuvent être des navigateurs d’utilisateurs normaux, mais également d’autres services tels que les robots d’exploration Web.

Vous pouvez créer un site qui utilise un GET pour insérer un enregistrement, mais vous devez également vous attendre à ce que tout ce qui est construit pour consumr votre site fonctionne avec l’hypothèse que vous respectez l’accord.

Comme dernier exemple, les navigateurs Web avertissent les utilisateurs lorsqu’ils essaient d’actualiser une page atteinte par une requête HTTP POST, avertissant que certaines données peuvent être soumises à nouveau. Vous n’obtenez pas cette couche de navigateurs intégrés de protection si la page est atteinte par une requête HTTP GET.

Vous pouvez en lire plus ici: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Mais quel est l’inconvénient si nous ne suivons pas cette règle ci-dessus, supposons d’insérer un enregistrement avec la méthode GET.

Les moteurs de recherche accèdent à vos pages à l’aide de requêtes GET. Si vous faites cela, le robot d’exploration de Google peut insérer des enregistrements dont vous ne vouliez pas.

Souvent, les utilisateurs utiliseront POST pour toute requête ajax, avec l’action réelle dans le corps de la requête. Il n’y a rien de très grave avec cela, mais la fonctionnalité est là pour que vous puissiez l’utiliser, vous pouvez aussi bien l’utiliser.

J’ai fait face à une situation que j’aurais dû utiliser le PUT au lieu de GET. J’ai eu un appel d’insertion de permission à un tiers (c’était google). Je lance une requête Ajax GET pour un appel d’autorisation de mise à jour sur mon Servlet et à partir de là, l’appel est allé vers un service externe. Le service externe a pris beaucoup de temps pour terminer la demande. Pendant ce temps, je voyais la duplication du même appel de permission dans les journaux de mon serveur. C’est le navigateur qui continue à appeler le serveur en disant que vous avez fini? étant donné que GET et le navigateur peuvent appeler le serveur autant de fois que possible. Le navigateur a suivi la norme et mon code ne l’a pas été. J’ai eu le problème de ne pas suivre la norme.