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?
Réponses:
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.
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.)
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.
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:
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.
À l'heure actuelle (2016), les derniers verbes HTTP sont GET, POST, PATCH , PUT et DELETE
Aperçu
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
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
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,
De manière générale, c'est le modèle que j'utilise:
Le projet Symfony essaie de maintenir ses méthodes HTTP liées aux méthodes CRUD, et leur liste les associe comme suit:
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.