S3 REST API et POST méthode
J'utilise AWS S3 REST API , et après avoir résolu quelques problèmes ennuyeux de signature, cela semble fonctionner. Toutefois, lorsque j'utilise correct REST verbe pour créer une ressource, à savoir POST, je reçois 405 method not allowed. La même demande fonctionne bien avec la méthode PUT et crée une ressource.
Est-ce que je fais quelque chose de mal ou AWS S3 REST n'est-il pas complètement compatible avec REST?
Oui, vous vous trompez en mappant CRUD aux méthodes HTTP.
En dépit de l’usage répandu et d’une idée fausse répandue, y compris des réponses de haut niveau, ici sur Stack Overflow, POST n’est pas la "méthode correcte pour créer une ressource". La sémantique des autres méthodes est déterminée par le protocole HTTP , mais la sémantique de POST est déterminée par le type de média cible lui-même. POST est la méthode utilisée pour toute opération non normalisée par HTTP.). il peut être utilisé pour la création, mais également pour les mises à jour, ou pour tout ce qui n'a pas déjà été fait par une autre méthode, par exemple, il est faux d'utiliser POST pour la récupération, car Vous avez normalisé GET pour cela, mais vous pouvez utiliser POST pour créer une ressource lorsque le client ne peut pas utiliser PUT pour une raison quelconque.
De la même manière, PUT n'est pas la "méthode correcte pour mettre à jour une ressource". PUT est la méthode utilisée pour remplacer complètement une ressource, en ignorant son état actuel. Vous pouvez utiliser PUT pour la création si vous avez la représentation complète attendue par le serveur, et vous pouvez utiliser PUT pour la mise à jour si vous fournissez une représentation complète, y compris les parties que vous ne modifierez pas, mais il est incorrect d'utiliser PUT pour les mises à jour partielles. , car vous demandez au serveur de prendre en compte l’état actuel de la ressource. PATCH est la méthode pour le faire.
En langage informel, chaque méthode dit au serveur:
[~ # ~] post [~ # ~] : prenez ces données et appliquez-les à la ressource identifiée par l'URI donné, en suivant les règles que vous avez documentées. pour le type de média ressource.
[~ # ~] mettez [~ # ~] : remplace tout ce qui est identifié par l'URI donné par ces données, en ignorant tout ce qui est déjà là, si n'importe quoi.
[~ # ~] patch [~ # ~] : si la ressource identifiée par l'URI donné a toujours le même état que celui qu'elle avait la dernière fois que j'ai regardé , appliquez ce diff à elle.
Notez que la création ou la mise à jour n'est pas mentionnée et ne fait pas partie de la sémantique de ces méthodes. Vous pouvez créer avec POST et PUT, mais pas PATCH, car cela dépend de l'état actuel. Vous pouvez mettre à jour avec n'importe lequel d'entre eux, mais avec PATCH, vous disposez d'une mise à jour conditionnelle à l'état souhaité. pour mettre à jour depuis, avec PUT vous mettez à jour en remplaçant l'entité entière, donc c'est une opération idempotente, et avec POST vous demandez au serveur de le faire selon des règles prédéfinies.
En passant, je ne sais pas s'il est logique de dire qu'une API est ou non conforme à REST, car REST est un style architectural , pas une spécification ou une norme, mais même si l'on considère que très peu d'API qui prétendent être REST sont vraiment RESTful, dans la plupart des cas parce qu'elles ne sont pas hypertexte driven . AWS S3 n'est certainement pas RESTful, bien que l'utilisation de méthodes HTTP soit conforme à la norme HTTP la plupart du temps.
+--------------------------------------+---------------------+
| POST | PUT |
+--------------------------------------+---------------------+
| Neither safe nor idempotent Ex: x++; | Idempotent Ex: x=1; |
+--------------------------------------+---------------------+
Ajouter à @Nicholos
De la http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
POST:
L'entité publiée est subordonnée à l'URI de la même manière qu'un fichier est subordonné à un répertoire qui le contient, qu'un article de presse est subordonné à un groupe de discussion auquel il est posté ou qu'un enregistrement est subordonné à une base de données.
L'action effectuée par la méthode POST peut ne pas aboutir à une ressource pouvant être identifiée par un URI. Dans ce cas, 200 (OK) ou 204 (aucun contenu) correspond au statut de réponse approprié. , selon que la réponse inclut ou non une entité qui décrit le résultat
Si une ressource a été créée sur le serveur d'origine, la réponse DEVRAIT être 201 (Créé).
PUT:
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. Si une nouvelle ressource est créée, le serveur d'origine DOIT informer l'agent d'utilisateur via la réponse 201 (Créé). Si une ressource existante est modifiée, les codes de réponse 200 (OK) ou 204 (pas de contenu) DEVRAIENT être envoyés pour indiquer que la demande a été traitée avec succès.
IMO PUT peut être utilisé pour créer ou modifier/remplacer l'entité incluse.
Dans spécification HTTP d'origine , la ressource indiquée dans la charge d'une demande POST) est "considérée comme subordonnée à l'objet spécifié" (c'est-à-dire l'URL de la demande). TimBL a dit précédemment (ne peut pas trouver la référence) qu'il a été modélisé sur la méthode du même nom dans NNTP .