HTTP PUT doit-il créer une ressource si elle n'existe pas?

Question

Supposons que quelqu'un exécute une requête PUT sur mon noeud final:

/resources/{id}

Cependant, il n'y a pas de ressource avec l'ID donné stocké dans ma base de données PostgreSQL.

Selon le RFC 2616 , je devrais créer la ressource si je suis capable de:

La méthode PUT demande que l'entité incluse soit stockée sous l'URI de demande fourni. Si l'URI de demande fait référence à une ressource déjà existante, l'entité incluse DEVRAIT être considérée comme une version modifiée de celle résidant sur le serveur d'origine. Si l'URI de demande ne pointe pas vers une ressource existante et que cet URI peut être défini comme nouvelle ressource par l'agent utilisateur demandeur, le serveur d'origine peut créer la ressource avec cet URI.

Serait d'accord pour créer la ressource avec l'ID fourni? L'attribution manuelle d'ID sur l'insertion de la base de données n'est pas la meilleure pratique.

Dois-je retourner un 404 erreur si la création de la ressource n'est pas possible?

Roman Vottner · Answer

En bref, cela dépend si la charge utile que vous souhaitez stocker viole ou non toute contrainte du serveur pour les ressources.

En général, je dirais qu'il devrait essayer car le client exprime explicitement son intention de stocker cette représentation particulière à l'URI cible. Le serveur doit cependant effectuer des vérifications de contraintes avant! Habituellement, dans un scénario réel REST cependant, le client doit utiliser l'URI fourni par le serveur et ne pas simplement choisir n'importe quel URI par lui-même. Par conséquent, un serveur doit contrôler son espace de noms , en tant que tel, l'utilisation de PUT pour créer des ressources n'est pas recommandée ici par défaut.

Cela étant dit, comme PUT est idempotent tandis que POST ne l'est pas, certains clients peuvent vouloir bénéficier de cette propriété. Ici, un modèle de création POST-PUT a évolué, où un client tente de créer une nouvelle ressource via POST jusqu'à ce qu'il reçoive une confirmation via un en-tête Location dans le réponse et tente ensuite la mise à jour de l'état de cette ressource via PUT. De cette façon, le client peut être sûr qu'en cas de problèmes de transmission, la représentation n'a été créée qu'une seule fois. Selon la position, certaines personnes peuvent considérer la mise à jour réelle de la ressource comme la création réelle de la ressource, bien que le client n'ait pas reçu le lien respectif, ce n'est pas tout à fait le cas.

Notez qu'un serveur a également le droit de transformer la représentation en quelque chose de différent si, par exemple, le serveur est configuré pour fournir des représentations spécifiques pour certains points de terminaison URI. Pensez à télécharger une image via PUT vers un URI et le serveur intègre l'image dans une page HTML