Je vais commencer à utiliser un travail de frame PHP REST appelé Slim et il y a de la documentation sur PUT et DELETE donc je me demande si je devrais m'en soucier si Je peux aussi supprimer un enregistrement sur ma base de données avec un GET ou un POST.Pourquoi utiliser PUT et DELETE quand je peux le faire avec POST ou GET
Y a-t-il des avantages?
convention de 99% , mais une convention utile.Il est pratique de savoir quel type de requête intervient et rend l'utilisation de l'API e asier (au lieu de forcer un dev à se rappeler d'ajouter action=blah, vous pouvez simplement leur dire "chaque fois que vous voulez supprimer quelque chose - même requête, DELETE verbe).
Le 1% restant est par un simple fait: en utilisant DELETE évite d'avoir à mettre un paramètre supplémentaire en GET ou POST variables pour signifier une suppression. Ce sont des octets sauvegardés sans avoir à vous répéter en choisissant un champ modifiable, plutôt que d'ajouter un champ supplémentaire. Il ne sert à rien d'ajouter de la complexité quand vous pouvez le faire sans le faire.
Les choses à surveiller comprennent également: idempotence des verbes. Ceci est une convention, cependant - GET devrait être idempotent car il est facilement déclenchable par les demandes du navigateur. Il devrait être "sûr de répéter".
(dernier bit utile: la plupart des frameworks MVC partagés points de terminaison par verbe HTTP vous sauve un si.!)
Est-ce que le downvoter pourrait dire pourquoi ils ont downvoted? –
exactement, tout est une question de convention.Je ne vois pas d'autre avantage pourquoi nous utilisons d'autres verbes http tels que put, delete, etc. BTW, comme pour éviter un paramètre supplémentaire qui nous permettrait de sauver un octet, nous pourrions également utiliser une autre méthode "DeleteCustomer" et il accepte Requête http avec juste un paramètre id (/ client/delete). Donc, de cette façon, nous allons toujours enregistrer un octet en ne spécifiant pas action paratmer. –
Elle est utilisée pour mapper les requêtes à l'action, en divisant le type de la requête en méta-information (GET) et les données réelles en tant que données dans la requête/corps (comme opéré pour envoyer une autre chaîne de requête . param qui indique l'action, comme action=delete ou /delete/ quelque part dans le uri
Vous avez choisi un cadre REST, qui utilise le REST "règles"
en savoir plus sur REST -. https://en.wikipedia.org/wiki/Representational_state_transfer
Tout ce que je dis, c'est que la partie de REST qui a défini ces GET/POST/PUT/DELETE est un moyen d'utiliser les méta-informations qui existent dans la requête comme le type de la requête, par opposition à spécifier type de ce que vous voulez faire avec les informations transmises via les paramètres de requête ou le corps des demandes. – Doron
en utilisant/foo/12/delete par opposition à object = foo & id = 12 & action = supprimer n'est pas pertinent - vous avez toujours utilisé l'action dans l'uri – Doron
"Par opposition .." est trompeur au mieux parce que la requête n'est pas * par opposition * au sujet précédent. – user2246674
Il y a peu de mal à utiliser POST pour faire SUPPRIMER, à l'exception du fait qu'il est moins évident les développeurs et les intermédiaires ne peuvent pas voir que vous supprimez quelque chose. Cependant, utiliser GET pour un DELETE serait une très mauvaise idée. La spécification HTTP indique qu'une opération GET doit être sûre et la suppression de quelque chose n'est pas sûre. Il y a beaucoup de raisons pratiques pour lesquelles vous ne devriez pas utiliser GET pour supprimer, un peu de googling devrait trouver beaucoup d'informations à ce sujet.
Utilisez PUT lorsque sa sémantique de "remplacement complet" correspond à votre scénario. Sinon, ne vous embêtez pas à mon humble avis.
Il s'agit simplement d'utiliser ces méthodes de requête pour ce qu'elles sont censées faire et cela rend la requête plus claire si la méthode utilisée définit en partie la requête elle-même. –
Eh bien, pourquoi s'embêter avec GET quand vous pouvez tout faire avec POST? :)) – moonwave99