En caso de no PUT usarse para Create y POSTAL utiliza para Update desde PUT es idempotente.RESTO - no debe poner = Crear y POST = Actualizar
De esta forma, múltiples PUT para el mismo pedido colocarán solo un pedido?
La diferencia fundamental es que un PUT es para un recurso conocido y, por lo tanto, se utiliza para actualizar, as stated here en rfc2616.
La diferencia fundamental entre las solicitudes POST y PUT es reflejada en el significado diferente de Request-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad adjunta. Ese recurso puede ser un proceso de aceptación de datos, una puerta de enlace a algún otro protocolo o una entidad separada que acepta anotaciones. En contraste, el URI en una solicitud PUT identifica la entidad incluida con la solicitud - el agente de usuario sabe qué URI está destinado y el servidor NO DEBE intentar aplicar la solicitud a algún otro recurso. Si el servidor desea que la solicitud puede aplicar a una URI diferente
Veo a qué atenerse a partir de la base de los nombres propios sin embargo.
Normalmente miro POST como debería ser el URI que manejará el contenido de mi solicitud (en la mayoría de los casos, los params como valores de formulario) y creando así un nuevo recurso, y PUT como el URI que es el tema de mi pedido (/ users/1234), un recurso que ya existe.
Creo que la nomenclatura se remonta un largo camino, considere la web temprana. Uno podría querer POST su mensaje a un tablero de mensajes, y luego PUT contenido adicional en su mensaje en una fecha posterior.
Para extender esto un poco, creo que podría ser más claro pensar en PUT como un sinónimo de "establecer" y POST como sinónimo de "crear hijo de". No pensaría ni en "crear" ni "actualizar" porque te dará una intuición equivocada. –
Buen punto @JohnWatts, este es el caso de uso típico, rara vez debe hacer algo fuera de lo común aquí. Si está manejando solicitudes de una manera no estándar, es posible que desee reconsiderar la intención de lo que está tratando de hacer en primer lugar. –
Martin Fowler dice "[algunas personas hacen incorrectamente una correspondencia entre' POST'/'PUT' y' create'/'update'] (http://martinfowler.com/articles/richardsonMaturityModel.html)" –
PUT se debe utilizar para crear si, y solo si es posible, el URI del nuevo recurso es conocido para un cliente. Es posible que el servicio publique una nueva URI en la representación de recursos. Por ejemplo, el servicio puede proporcionar algún tipo de formulario de envío y especificar el URI de acción en él, que puede ser un URI prepoblado del nuevo recurso. En este caso sí, si la solicitud PUT inicial crea recursos con éxito después de la solicitud PUT solo la reemplazará.
Está bien utilizar el POST para las actualizaciones, nunca se dijo que el POST es solo para operaciones de "creación".
Depende de .. puede crear/actualizar sitios/registros con ambos. Cuando el cliente especifica el URI, entonces PUT es el camino a seguir. p. Cualquier editor de código como Dreamweaver, PUT es el protocolo correcto para usar.
tienen también un vistazo a este tema: put vs post in rest
No es que pueda crearlos o actualizarlos con cualquier tipo de solicitud, de hecho puede crear un recurso con un GET o ELIMINAR si realmente lo desea. Tiene mucho que ver con las convenciones de REST. En cualquier caso, debe especificar un URI en cualquier solicitud. –
No hay correspondencia estricta entre los métodos HTTP y ABM. Esta es una convención adoptada por algunos marcos, pero no tiene nada que ver con las restricciones REST.
Una solicitud PUT pide al servidor que reemplace lo que está en el URI dado con la representación adjunta, ignorando por completo el contenido actual. Una buena analogía es el comando mv en un shell. Crea el nuevo archivo en el destino si no existe, o reemplaza lo que exista.En cualquier caso, ignora por completo lo que está allí. Puede usar esto para crear, pero también para actualizar algo, siempre que envíe una representación completa.
POST le pide al recurso de destino que procese la carga de acuerdo con reglas predefinidas, por lo que es el método que se debe utilizar para cualquier operación que no esté ya estandarizada por el protocolo HTTP. Esto significa que POST puede hacer lo que desee, siempre que no esté duplicando la funcionalidad de otro método, por ejemplo, usando POST para recuperar cuando debe usar GET, y lo documente correctamente.
Así que puede usar ambos para crear y actualizar, dependiendo de las circunstancias exactas, pero con PUT debe tener una semántica consistente para todo en su API y no puede hacer actualizaciones parciales, y con POST puede hacer cualquier cosa usted quiere, siempre y cuando documente cómo funciona exactamente.
Creo que esta es la respuesta más simplista y agnóstica. No importa el marco, la metodología REST, depende del proceso que desee fomentar el verbo que debe imponer. PUT hará una cosa, ¡PUBLICAR lo que quieras hacer! ¡Cristal claro! –
ver http://stackoverflow.com/questions/630453/put-vs-post-in-rest/2590281#2590281 –