update method example and api rest post upload put

api - method - rest put example



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

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 refiérase a: PUT o POST: El RESTO de la historia

La forma en que entiendo esto es que debería usar PUT solo 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 es 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 imágenes (es decir, crear miniaturas, cambiar el tamaño, etc.); y use PUT si simplemente guardo el archivo raw de imagen en el servidor?

Si utilizo PUT para gestionar la carga de archivos, el proceso debería ser el siguiente:

  1. El usuario envía una solicitud GET para recuperar la URL específica para el archivo que se PUT.
  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; así que espero tener sentido aquí ...

Si conoce la "mejor" manera de hacer esto, siéntase libre de comentar también.

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

Tendré que saber la URL exacta para PONER a

No. No es necesario que conozca la URL para PUT, es decir, el URI PUT 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.

Para citar el artículo vinculado:

PUT pone una página en una URL específica. Si ya hay una página allí, se reemplaza en toto. Si no hay una página allí, se crea una nueva. Esto significa que es como un DELETE seguido de un inserto de un nuevo registro con la misma clave primaria

Parece que hay bastante malentendido aquí. PUT versus POST no se trata de reemplazar o crear, sino más bien de idempotencia y denominación 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 haber creado (ni tampoco debe crear un POST, ya que podría desduplicar recursos si 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 toma la posición política de que los clientes nunca deben crear nombres de recursos, entonces obtiene POST siendo el ajuste perfecto para la creación (aunque teóricamente podría hacer cualquier cosa en función de la entidad suministrada) y PUT es cómo 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 a cosas menos comunes como crear un directorio vacío y así 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 los recursos y qué operaciones son idempotentes. PUT es realmente create-or-update, y POST es realmente do-anything-which-should-be-repeat-willy-nilly.

REST no es un estándar así que esto 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