PUT et POST dans REST

Selon la spécification HTTP/1.1 :

La méthode POST est utilisée pour demander au serveur d'origine d'accepter l'entité incluse dans la requête comme un nouveau subordonné de la ressource identifiée par le Request-URI dans le Request-Line.

En d'autres termes, la méthode POST est utilisée pour créer.

La méthode PUT demande que l'entité jointe soit stockée sous le Request-URI fourni. Si le Request-URI fait référence à une ressource déjà existante, l'entité jointe devrait être considérée comme une version modifiée de celle qui réside sur le serveur d'origine. Si le Request-URI 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.&quot ;

C'est-à-dire que PUT est utilisé pour créer ou mettre à jour.

Alors, lequel des deux doit être utilisé pour créer une ressource ? Ou faut-il supporter les deux ?

Peter Mortensen
Question modifiée 22 juillet 2017 в 11:39
Programmation
rest http post put
10 mars 2009 в 2:25
22 vues
Solution

Général:

PUT et POST peuvent tous deux être utilisés pour la création.

Vous devez vous demander "sur quoi porte l'action ?" pour distinguer ce que vous devez utiliser. Supposons que vous conceviez une API pour poser des questions. Si vous voulez utiliser POST, vous le ferez sur une liste de questions. Si vous voulez utiliser PUT, vous le ferez pour une question particulière.

Les deux peuvent être utilisés, alors lequel dois-je utiliser dans ma conception RESTful :

Il n'est pas nécessaire de prendre en charge à la fois PUT et POST.

C'est à vous de choisir lequel utiliser. Mais n'oubliez pas d'utiliser la bonne méthode en fonction de l'objet auquel vous faites référence dans la requête.

Quelques considérations :

  • Nommez-vous les objets URL que vous créez explicitement, ou laissez-vous le serveur décider ? Si vous les nommez, utilisez PUT. Si vous laissez le serveur décider, utilisez POST.
  • PUT est idempotent, donc si vous PUT un objet deux fois, cela n'a aucun effet. C'est une propriété intéressante, c'est pourquoi j'utiliserais PUT lorsque cela est possible.
  • Vous pouvez mettre à jour ou créer une ressource avec PUT avec la même URL d'objet.
  • Avec POST, vous pouvez avoir 2 requêtes qui arrivent en même temps pour modifier une URL, et elles peuvent mettre à jour différentes parties de l'objet.

Un exemple:

[J'ai écrit ce qui suit dans le cadre d'une autre réponse sur SO à ce sujet][1] :

POST:

Utilisé pour modifier et mettre à jour une ressource

POST /questions/ HTTP/1.1 Hôte : www.example.com/

Notez que ce qui suit est une erreur :

POST /questions/ HTTP/1.1 Hôte : www.example.com/

Si l'URL n'est pas encore créée, vous ne devez pas utiliser POST pour la créer. Si l'URL n'est pas encore créée, vous ne devriez pas utiliser POST pour la créer tout en spécifiant le nom. tout en spécifiant le nom. Cela devrait une erreur 'resource not found' (ressource non trouvée). parce que n'existe pas n'existe pas encore. Vous devez d'abord placer la ressource sur le serveur en premier.

Vous pouvez cependant faire quelque chose comme pour créer une ressource en utilisant POST :

POST /questions HTTP/1.1 Hôte : www.example.com/

Notez que dans ce cas, la ressource nom de la ressource n'est pas spécifié, les nouveaux objets URL vous serait renvoyé.

PUT:

Utilisé pour créer une ressource, ou l'écraser. Alors que vous spécifiez la nouvelle URL de la ressource.

Pour une nouvelle ressource :

PUT /questions/ HTTP/1.1 Hôte : www.example.com/

Pour écraser une ressource existante :

PUT /questions/ HTTP/1.1 Hôte : www.example.com/

[1] : https://stackoverflow.com/questions/256349/what-are-the-best-common-restful-url-verbs-and-actions/256359#256359

Community
Réponse modifiée 23 mai 2017 в 11:55
Commentaires (41)

Utilisez POST pour créer, et PUT pour mettre à jour. C'est ainsi que Ruby on Rails procède, en tout cas.

PUT    /items/1      #=> update
POST   /items        #=> create
Peter Mortensen
Réponse modifiée 16 septembre 2017 в 8:17
Commentaires (8)

REST est un concept de très haut niveau. En fait, il ne mentionne même pas HTTP !

Si vous avez des doutes sur la manière de mettre en œuvre REST dans HTTP, vous pouvez toujours consulter la spécification [Atom Publication Protocol (AtomPub)][1]. AtomPub est une norme permettant d'écrire des services Web RESTful avec HTTP. Elle a été développée par de nombreuses personnalités de HTTP et de REST, avec la contribution de Roy Fielding, l'inventeur de REST et (co-)inventeur de HTTP lui-même.

En fait, vous pourriez même être en mesure d'utiliser directement AtomPub. Bien qu'il soit issu de la communauté des blogueurs, il n'est en aucun cas limité aux blogs : il s'agit d'un protocole générique pour interagir de manière REST avec des collections arbitraires (imbriquées) de ressources arbitraires via HTTP. Si vous pouvez représenter votre application comme une collection imbriquée de ressources, vous pouvez alors utiliser AtomPub sans vous soucier de savoir s'il faut utiliser PUT ou POST, quels codes d'état HTTP renvoyer et tous ces détails.

Voici ce qu'AtomPub a à dire sur la création de ressources (section 9.2) :

Pour ajouter des membres à une collection, les clients envoient des requêtes POST à l'URI de la collection. [1] : https://www.ietf.org/rfc/rfc5023.txt

Xan
Réponse modifiée 27 juillet 2018 в 2:37
Commentaires (9)