PUT vs. POST para cargar archivos RESTful api para ser construido usando Zend Framework

Question

Estoy construyendo una API REST con Zend Framework a través de Zend_Rest_Route. Para la carga de archivos, ¿debo usar PUT o POST para manejar el proceso? Intento ser lo más constante posible con la definición de los verbos REST. Por favor, consulte: PUT or POST: The REST of the Story

mi modo de entender esto es que debo utilizar PUT si y sólo si estoy actualizando el contenido completo del recurso especificado. Tendré que saber la URL exacta para PONER a. Por otro lado, debería usar POST si estoy enviando un comando al servidor para crear un subordinado del recurso especificado, usando algún algoritmo del lado del servidor.

Supongamos que se trata de una APLICACIÓN REST para la carga de imágenes. ¿Eso significa que debería usar POST si el servidor debe manipular los archivos de imagen (es decir, crear miniaturas, cambiar el tamaño, etc.); y use PUT si simplemente guardo el archivo raw de imagen en el servidor?

si uso PUT para manejar la carga de archivos, debe ser el proceso de la siguiente manera:

1. usuario envía una solicitud GET para recuperar la dirección URL específica para el archivo para ser puesto a.
2. Luego el usuario envía la solicitud PUT a la URL desde la respuesta GET. El archivo que se carga está sin procesar exactamente como lo subió el usuario.

Soy bastante nuevo en esto; entonces espero tener sentido aquí ...

Si conoce la "mejor" manera de hacerlo, no dude en comentar también.

Answer 1

Parece que hay un poco de malentendido. PUT versus POST no es realmente sobre reemplazar versus crear, sino más bien sobre idempotencia y nomenclatura de recursos.

PUT es una operación idempotente. Con él, le da el nombre de un recurso y una entidad para colocar como contenido de ese recurso (posiblemente con adiciones generadas por el servidor). Fundamentalmente, hacer la operación dos veces seguidas debería dar como resultado lo mismo que si se hubiera hecho una sola vez o hecho 20 veces, para una definición bastante suelta de "lo mismo" (no tiene que ser un byte para el byte es idéntico, pero la información que el usuario suministró debe estar intacta). No querrá nunca un PUT para provocar el desencadenamiento de una transacción financiera.

POST es una operación no idempotente. No es necesario que proporcione el nombre del recurso que desea crear (ni POST tiene para crear; podría desduplicar los recursos si así lo desea). POST a menudo se usa para implementar "crear un recurso con un nombre recién acuñado y decirme cómo se llama": la falta de idempotencia implícita en el "nombre recién acuñado" encaja con eso. Cuando se crea un nuevo recurso, devolver el localizador para el recurso en un encabezado de Ubicación es completamente lo correcto.

Ahora, si usted está tomando la posición política que los clientes deben Nunca crear nombres de recursos, a continuación, obtener la POST ser el ajuste perfecto para la creación (aunque teóricamente se podría hacer nada sobre la base de la entidad suministrado) y poner siendo cómo para hacer la actualización Para muchas aplicaciones RESTful tiene mucho sentido, pero no todas; si el modelo que se presenta al usuario era de un sistema de archivos, hacer que el usuario proporcione el nombre del recurso tiene mucho sentido y PUT se convierte en la operación de creación principal (y POST se delega en cosas menos comunes, como crear un directorio vacío, etc. on; WebDAV reduce la necesidad de POST incluso más).

El resumen: No piense en términos de crear/actualizar, sino en términos de quién hace los nombres de recursos y qué operaciones son idempotentes. PUT es realmente create-or-update, y POST es realmente do-anything-which-should-be-repeat-willy-nilly.

Answer 2

La respuesta simple es que debe usar PUT en lugar de POST en su caso, ya que reemplazará todo el contenido del archivo. Echar un vistazo a PUT vs POST

Voy a tener que saber la URL exacta a PUT a

No. Usted no tiene que conocer la dirección URL a PUT PUT es decir, el URI no necesita estar presente antes de la operación PUT. Si el recurso no existe, se crea el recurso. Si el recurso ya está presente, el recurso se reemplaza con la nueva representación.

citar el artículo enlazado:

PUT pone una página en una URL específica. Si ya hay una página allí, es reemplazado en su totalidad. Si no hay una página allí, se crea una nueva. Esto significa que es como un DELETE seguida de una inserción de un nuevo registro con la misma clave primaria

Answer 3

resto no es un estándar por lo que este puede convertirse fácilmente en una batalla religiosa. Los estándares AtomPub y OData que se consideran "RESTful" sí lo acuerdan: POST = creación mientras PUT = actualizaciones

Answer 4

Para cargar archivos, a menos que esté reemplazando un recurso existente, definitivamente use POST.

En REST, POST creará nuevos recursos, PONER para reemplazar recursos existentes, OBTENER para recuperar recursos y ELIMINAR para eliminar recursos.

Fuente: http://en.wikipedia.org/wiki/Representational_state_transfer#RESTful_web_services