PUT vs. POST pour les fichiers upload api RESTful à construire en utilisant Zend Framework
Je construis une API RESTful en utilisant Zend Framework via Zend_Rest_Route. Pour le téléchargement de fichiers, dois-je utiliser PUT ou POST pour gérer le processus? J'essaie d'être aussi cohérent que possible avec la définition des verbes REST Veuillez vous référer à: PUT or POST: The REST of the Story
La façon dont je comprends cela est que je devrais utiliser PUT si et seulement si je mets à jour le contenu complet de la ressource spécifiée. Je devrai connaître l'URL exacte à PUT. D'un autre côté, je devrais utiliser POST si j'envoie une commande au serveur pour créer un subordonné de la ressource spécifiée, en utilisant un algorithme côté serveur.
Supposons qu'il s'agit d'une api REST pour le téléchargement d'images. Cela signifie-t-il que je devrais utiliser POST si le serveur doit manipuler les fichiers image (c.-à-d. Créer une miniature, redimensionner , etc); et utiliser PUT si je sauvegarde simplement le fichier brut d'image sur le serveur?
Si j'utilise PUT pour gérer le téléchargement de fichiers, le processus devrait-il être le suivant:
- L'utilisateur envoie une demande GET pour récupérer l'URL spécifique du fichier à PUT.
- Ensuite, l'utilisateur envoie une demande PUT à l'URL à partir de la réponse GET. Le fichier en cours de téléchargement est brut exactement comme l'utilisateur l'a téléchargé.
Je suis assez nouveau dans ce domaine; alors j'espère que j'ai du sens ici ...
Si vous connaissez la "meilleure" façon de procéder, n'hésitez pas à commenter également.
Il semble y avoir un certain malentendu ici. PUT versus POST n'est pas vraiment sur remplacer versus créer, mais plutôt sur l'idempotence et la dénomination des ressources.
PUT est une opération idempotente. Avec lui, vous donnez le nom d'une ressource et d'une entité à placer comme contenu de cette ressource (éventuellement avec des ajouts générés par le serveur). De manière cruciale, faire l'opération deux fois de suite devrait avoir pour résultat la même chose que si elle était effectuée une seule fois ou 20 fois, pour une définition assez vague de "la même chose" (il n'est pas nécessaire qu'elle soit octet par- octet identique, mais les informations fournies par l'utilisateur doivent être intactes). Vous ne voudriez jamais qu'un PUT provoque le déclenchement d'une transaction financière.
POST est une opération non idempotente. Vous n'avez pas besoin de donner le nom de la ressource que vous cherchez à créer (pas plus qu'un POST n'a pour créer; il pourrait dédoublonner les ressources s'il le souhaitait.) POST est souvent utilisé pour implémenter "créer une ressource avec un nom nouvellement créé et me dire quel est le nom") - le manque d'idempotence impliqué par le "nom nouvellement créé" correspond à cela. Lorsqu'une nouvelle ressource est créée, renvoyer le localisateur de la ressource dans un en-tête Location est tout à fait la bonne chose à faire.
Maintenant, si vous adoptez la position politique que les clients ne doivent jamais créer des noms de ressources, vous obtenez alors POST étant le ajustement parfait pour la création (bien que théoriquement, cela puisse faire n'importe quoi en fonction de l'entité fournie) et PUT étant la façon de mettre à jour. Pour de nombreuses applications RESTful, cela a beaucoup de sens, mais pas toutes; si le modèle présenté à l'utilisateur était de un système de fichiers, le fait que l'utilisateur fournisse le nom de la ressource a beaucoup de sens et PUT devient l'opération de création principale (et POST devient délégué à des choses moins courantes comme créer un répertoire vide, etc.) ; WebDAV réduit encore plus le besoin de POST).
Le résumé: Ne pensez pas en termes de création/mise à jour, mais plutôt en termes de qui fait les noms des ressources et quelles opérations sont idempotentes. PUT est vraiment create-or-update, et POST est vraiment tout-ce-qui-ne-doit-pas-être-répété-bon gré mal gré).
Pour le téléchargement de fichiers, à moins qu'il ne remplace une ressource existante, utilisez définitivement POST.
Dans REST, POST sert à créer de nouvelles ressources, PUT pour remplacer les ressources existantes, GET pour récupérer les ressources et DELETE pour supprimer les ressources.
Source: http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services
REST n'est pas une norme, donc cela peut facilement se transformer en bataille religieuse. Les normes AtomPub et OData qui sont considérées comme "RESTful" sont d'accord sur ce point cependant: POST = creation while PUT = updates
La réponse simple est que vous devez utiliser PUT au lieu de POST dans votre cas car vous allez remplacer tout le contenu du fichier. Jetez un œil à PUT vs POST
Je vais devoir connaître l'URL exacte à mettre
Non. Vous n'avez pas besoin de connaître l'URL de PUT, c'est-à-dire que l'URI PUT n'a pas besoin d'être présent avant l'opération PUT. Si la ressource n'existe pas, la ressource est créée. Si la ressource est déjà présente, alors la ressource est remplacée par la nouvelle représentation.
Pour citer l'article lié:
PUT met une page à une URL spécifique. S'il y a déjà une page, elle est remplacée en totalité. S'il n'y a pas de page, une nouvelle est créée. Cela signifie que c'est comme une SUPPRESSION suivie de l'insertion d'un nouvel enregistrement avec la même clé primaire