Dans REST est POST ou PUT est-il le mieux adapté aux opérations d'Usert?
Je garde un stockage clé-valeur sur le serveur pour le client. Si l'utilisateur envoie la clé "k1", je la transfère dans la base de données. Est-ce considéré comme POST ou PUT?
Aussi, j'ai une autre opération qui supprime toutes les clés existantes et ajoute la nouvelle clé. Est-ce POST ou PUT parce qu'il efface les enregistrements et en ajoute un nouveau.
Si l'utilisateur envoie la clé "k1", je la transfère dans la base de données. Est-ce considéré comme POST ou PUT.
Selon la spécification HTTP :
La méthode PUT demande à ce 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 Request-URI ne pointe pas vers une ressource existante et que cet URI peut être défini en tant que nouvelle ressource par l'agent utilisateur demandeur, le serveur d'origine peut créer la ressource avec cet URI.
Je pense donc que l'utilisation de PUT pour une insertion ou une mise à jour est parfaitement légitime, à condition que dans les deux cas, l'URI soit connu à l'avance. Si vous utilisez la clé dans le cadre de l'URI (comme k1 dans http://www.somewhere.com/resources/k1 ), cela devrait être le cas. Pour être idéalement RESTful, cependant, un GET sur la même URL devrait également vous permettre de télécharger la ressource.
De plus, j'ai une autre opération qui supprime toutes les clés existantes et ajoute la nouvelle, est-ce POST ou PUT car cela efface les enregistrements et en ajoute un nouveau.
Je ne pense pas que cette opération puisse être considérée comme reposante car elle fait deux choses. Il semble fournir une macro pour satisfaire les besoins d'un client particulier, plutôt qu'un simple accès aux données. Une conception standard RESTful serait
- Obtenir une liste de clés en envoyant un GET à l'URL parent. Dans l'exemple ci-dessus, ce serait http://www.somewhere.com/resources ;
- Suppression de chacune de ces clés en envoyant un message DELETE à http://www.somewhere.com/resources/k1 ;
- Ajout du remplacement en envoyant un PUT à http://www.somewhere.com/resources/k2 .
C'est moins clair, mais je pense qu'il serait également légitime de supprimer toutes les ressources en envoyant une seule requête DELETE à http://www.somewhere.com/resources .
La réponse de Polly Shaw est correcte, mais je voudrais mentionner que, étant donné que le message pourrait très probablement être incomplet (il manque l'ID lorsque la ressource n'est pas encore créée), un verbe PATCH serait légèrement plus correct.
https://tools.ietf.org/html/rfc5789
C'est un réglage extrêmement fin.
L’idée de l’opération upsert est que les clients disposent d’informations sur la structure de données et décident de l’envoi de données avec une valeur clé. Ainsi, le modèle de requête pour l'opération upsert est très similaire à l'opération de mise à jour avec la clé incluse dans l'exemple ci-dessous:
/customers/jimmy
La méthode attendue pour mettre à jour un enregistrement existant est PUT. Donc, votre choix devrait être PUT.
POST est généralement utilisé pour insérer un nouvel enregistrement avec un nouveau contenu, comme dans l'exemple ci-dessous:
POST /customers HTTP/1.1
Content-Type: ...
Content-Length: ...
Host: server.yourdomain.com
Accept: ...
User-Agent: ...
id jimmy
name jimmy
Occupation Stackoverflower
Donc, dans votre cas, vous n'avez besoin d'aucune opération POST car PUT pour l'opération d'Usert couvre également cela.
Ici, la question cruciale à propos de l’upert est de savoir quelle est la probabilité que vous fassiez confiance à votre client pour le fonctionnement de l’opération. Si un client souhaite insérer un nouvel enregistrement avec une clé existante, que se passe-t-il? Dans votre cas, vous devez traiter cette demande comme une mise à jour car les demandes d'insertion et de mise à jour arrivent à la même API et vous avez un enregistrement existant. Telle est la question à laquelle vous devez répondre concernant le design.