Quelles méthodes HTTP correspondent à quelles méthodes CRUD?

213

Dans la programmation de style RESTful, nous devons utiliser les méthodes HTTP comme blocs de construction. Je suis un peu confus quant aux méthodes qui correspondent aux méthodes CRUD classiques. GET / Read et DELETE / Delete sont assez évidents.

Cependant, quelle est la différence entre PUT / POST? Correspondent-ils un à un avec Créer et mettre à jour?

A dessiné
la source

Réponses:

298
Create = PUT with a new URI
         POST to a base URI returning a newly created URI
Read   = GET
Update = PUT with an existing URI
Delete = DELETE

PUT peut mapper à la fois sur Create et Update en fonction de l'existence de l'URI utilisé avec le PUT.

POST mappe sur Créer.

Correction: POST peut également mapper vers Update bien qu'il soit généralement utilisé pour Create. POST peut également être une mise à jour partielle, nous n'avons donc pas besoin de la méthode PATCH proposée.

Paul Morgan
la source
16
+1: La distinction que vous faites entre PUT pour créer des ressources dont les noms (URI) sont attribués par le client et POST pour créer des ressources dont les noms sont attribués par le serveur est importante. Voir Richardson et Ruby's Restful Web Services (O'Reilly) pour une discussion à ce sujet.
Jim Ferrans
9
Et puisque PUT et DELETE ne sont pas encore pris en charge par les navigateurs Web, il est considéré comme correct de "surcharger POST" en ajoutant un argument de chaîne de requête comme method = PUT ou method = DELETE sur l'URI en cours de publication.
Jim Ferrans
2
Nice analyses jcalcote.wordpress.com/2008/10/16/…
Boris Ivanov
13
@JimFerrans PUT et DELETE sont très bien pris en charge par les navigateurs Web, avec XHR. Cependant, dans le contexte des formulaires HTML, la spécification HTML ne les prend pas en charge, les navigateurs ne le peuvent pas non plus.
eis
3
Bien qu'ils ne soient pas canoniquement mappés à une lettre dans CRUD, de nombreux frameworks REST utilisent également GET / entity / to List des entités de type entity . GET / entity / id lira l'entité particulière correspondant à l' id .
Toddius Zho
49

L'essentiel est de savoir si vous faites un changement idempotent ou non. Autrement dit, si une action sur le message deux fois se traduira par «la même» chose comme si elle n'avait été effectuée qu'une seule fois, vous avez un changement idempotent et il devrait être mappé sur PUT. Sinon, il est mappé sur POST. Si vous ne permettez jamais au client de synthétiser des URL, PUT est assez proche de Update et POST peut gérer Create très bien, mais ce n'est certainement pas la seule façon de le faire; si le client sait qu'il veut créer /foo/abcet sait quel contenu y mettre, cela fonctionne très bien comme un PUT.

La description canonique d'un POST est lorsque vous vous engagez à acheter quelque chose: c'est une action que personne ne veut répéter sans le savoir. En revanche, la définition préalable de l'adresse d'expédition pour la commande peut être effectuée avec PUT: cela n'a pas d'importance si on vous dit d'envoyer 6 Anywhere Dr, Nowherevilleune fois, deux ou cent fois: c'est toujours la même adresse. Est-ce à dire que c'est une mise à jour? Cela pourrait être… Tout dépend de la façon dont vous voulez écrire le back-end. (Notez que les résultats peuvent ne pas être identiques: vous pouvez signaler à l'utilisateur la dernière fois qu'il a effectué un PUT dans le cadre de la représentation de la ressource, ce qui garantirait que les PUT répétés ne provoquent pas un résultat identique, mais le résultat serait toujours être «le même» dans un sens fonctionnel.)

Associés Donal
la source
1
Cette distinction entre les cas d'utilisation de POSTet PUTest intéressante, et devrait apporter la réponse à "qui est" créer "et qui est" mettre à jour "?" que beaucoup plus clair. En outre, en ce qui concerne la mise en œuvre de l'API, il s'ensuivrait qu'un répétitif PUTdevrait équivaloir à un non-fonctionnement silencieux, tandis qu'un répétitif POSTpourrait lever une exception si un aspect des données envoyées est censé rester unique dans le magasin de données. qui soutient l'application.
zerobandwidth
2
Cette réponse et le commentaire suivant soulèvent un point important, que la prudence doit être exercée en assimilant CRUD à étroitement (1to1) avec la sémantique HTTP REST. Ce n'est pas un mappage canonique.
Martin Spamer
35

Je cherchais la même réponse, voici ce que dit IBM. IBM Link

POST            Creates a new resource.
GET             Retrieves a resource.
PUT             Updates an existing resource.
DELETE          Deletes a resource.
ex0b1t
la source
10

Il y a une excellente conversation vidéo sur YouTube par Stormpath avec explique en fait cela, l'URL devrait passer à la bonne partie de la vidéo:

vidéo youtube de stormpath

Cela vaut également la peine de regarder, c'est plus d'une heure de conversation, mais très intéressant si vous songez à investir du temps dans la construction d'une API REST.

pleshy
la source
10

À l'heure actuelle (2016), les derniers verbes HTTP sont GET, POST, PATCH , PUT et DELETE

Aperçu

  • HTTP GET - SELECT / Request
  • HTTP PUT - UPDATE
  • HTTP POST - INSERT / Create
  • PATCH HTTP - Lorsque PUT une représentation complète des ressources est lourde et utilise plus de bande passante, par exemple: lorsque vous devez mettre à jour partiellement une colonne
  • SUPPRIMER HTTP - SUPPRIMER

J'espère que cela t'aides!

Si vous êtes intéressé par la conception d'API REST, c'est une lecture ansewome à avoir! site Web version en ligne dépôt github

d1jhoni1b
la source
1
Depuis février 18, sachez que PATCH n'est pas complètement implémenté dans les bibliothèques client et serveur.
Dizzley
oh ok merci je vois ... cela vous dérangerait de poster un lien / référence afin que je puisse y jeter un œil s'il vous plaît?
d1jhoni1b
7

Cela dépend de la situation concrète .. mais en général:

PUT = mettre à jour ou modifier une ressource concrète avec un URI concret de la ressource.

POST = créer une nouvelle ressource sous la source de l'URI donné.

C'est à dire

Modifier un article de blog:

PUT: / blog / entry / 1

Créez-en un nouveau:

POST: / blog / entrée

PUT peut créer une nouvelle ressource dans certaines circonstances où l'URI de la nouvelle ressource est clair avant la demande. POST peut également être utilisé pour implémenter plusieurs autres cas d'utilisation, qui ne sont pas couverts par les autres (GET, PUT, DELETE, HEAD, OPTIONS)

La compréhension générale des systèmes CRUD est GET = demande, POST = créer, Put = mettre à jour, DELETE = supprimer

Coincé
la source
4

Les éléments constitutifs de REST sont principalement les ressources (et l'URI) et l'hypermédia. Dans ce contexte, GETest le moyen d'obtenir une représentation de la ressource (qui peut en effet être mise en correspondance avec un SELECTen termes CRUD).

Cependant, vous ne devez pas nécessairement vous attendre à un mappage un à un entre les opérations CRUD et les verbes HTTP. La principale différence entre PUTet POSTconcerne leur propriété idempotente. POSTest également plus couramment utilisé pour les mises à jour partielles, car il PUTimplique généralement l'envoi d'une nouvelle représentation complète de la ressource.

Je suggère de lire ceci:

La spécification HTTP est également une référence utile:

La méthode PUT demande que l'entité incluse soit stockée sous l'URI de demande fourni.

[...]

La différence fondamentale entre les requêtes POST et PUT se reflète dans la signification différente de l'URI de demande. L'URI dans une demande POST identifie la ressource qui gérera l'entité incluse. Cette ressource peut être un processus d'acceptation de données, une passerelle vers un autre protocole ou une entité distincte qui accepte les annotations. En revanche, l'URI dans une demande PUT identifie l'entité jointe à la demande - l'agent utilisateur sait quel URI est prévu et le serveur NE DOIT PAS tenter d'appliquer la demande à une autre ressource. Si le serveur souhaite que la demande soit appliquée à un autre URI,

Bruno
la source
3

De manière générale, c'est le modèle que j'utilise:

  • HTTP GET - SELECT / Request
  • HTTP PUT - UPDATE
  • HTTP POST - INSERT / Create
  • SUPPRIMER HTTP - SUPPRIMER
UN J.
la source
5
PUT et POST ne correspondent pas exactement à Update ou Create; PUT est "set" (c'est-à-dire où vous connaissez le nom de la ressource au préalable et donnez la valeur à utiliser) et POST est tout le reste. La clé est de savoir si ce que vous faites est idempotent ou non.
Donal Fellows
1
+1 sur le commentaire. L'hypothèse d'une correspondance absolue entre les deux peut être trompeuse. Une opération HTTP DELETE vers un URI, par exemple, pourrait simplement modifier (c.-à-d. METTRE À JOUR) un enregistrement côté serveur afin qu'une opération HTTP GET ne renvoie plus de représentation.
stand
4
PUT et POST ne correspondent pas exactement à Update ou Create . Certes, mais AJ a décrit le modèle qu'il utilise.
Piotr Dobrogost
1

Le projet Symfony essaie de maintenir ses méthodes HTTP liées aux méthodes CRUD, et leur liste les associe comme suit:

  • GET Récupérer la ressource du serveur
  • POST Créer une ressource sur le serveur
  • Mettre à jour la ressource sur le serveur
  • DELETE Supprimer la ressource du serveur

Il convient de noter que, comme ils le disent sur cette page, "En réalité, de nombreux navigateurs modernes ne prennent pas en charge les méthodes PUT et DELETE."

D'après ce dont je me souviens, Symfony "simule" PUT et DELETE pour les navigateurs qui ne les prennent pas en charge lors de la génération de ses formulaires, afin d'essayer d'être aussi proche de l'utilisation de la méthode HTTP théoriquement correcte même lorsqu'un navigateur ne prend pas en charge il.

Matt Gibson
la source