Respuestas:
HTTP PUT:
PUT coloca un archivo o recurso en un URI específico y exactamente en ese URI. Si ya hay un archivo o recurso en ese URI, PUT reemplaza ese archivo o recurso. Si no hay ningún archivo o recurso allí, PUT crea uno. PUT es idempotente , pero paradójicamente, las respuestas PUT no son almacenables en caché.
Ubicación HTTP 1.1 RFC para PUT
POST HTTP:
POST envía datos a un URI específico y espera que el recurso en ese URI maneje la solicitud. El servidor web en este punto puede determinar qué hacer con los datos en el contexto del recurso especificado. El método POST no es idempotente , sin embargo, las respuestas POST se pueden almacenar en caché siempre que el servidor establezca los encabezados Cache-Control y Expires apropiados.
El HTTP RFC oficial especifica que POST sea:
Ubicación HTTP 1.1 RFC para POST
Diferencia entre POST y PUT:
El RFC en sí mismo explica la diferencia central:
La diferencia fundamental entre las solicitudes POST y PUT se refleja en el significado diferente del Request-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad adjunta. Ese recurso podría ser un proceso de aceptación de datos, una puerta de enlace a algún otro protocolo o una entidad separada que acepte anotaciones. Por el contrario, el URI en una solicitud PUT identifica la entidad adjunta a la solicitud: el agente de usuario sabe a qué se destina el URI y el servidor NO DEBE intentar aplicar la solicitud a otro recurso. Si el servidor desea que la solicitud se aplique a un URI diferente, DEBE enviar una respuesta 301 (movida permanentemente); el agente de usuario PUEDE tomar su propia decisión con respecto a redirigir o no la solicitud.
Además, y de manera un poco más concisa, RFC 7231 Sección 4.3.4 Estados PUT (énfasis agregado),
4.3.4. PONER
El método PUT solicita que el estado del recurso de destino sea
createdoreplacedcon el estado definido por la representación incluida en la carga útil del mensaje de solicitud.
Usando el método correcto, sin relación aparte:
Un beneficio de REST ROA vs SOAP es que cuando se utiliza HTTP REST ROA, se fomenta el uso adecuado de los verbos / métodos HTTP. Entonces, por ejemplo, solo usaría PUT cuando desee crear un recurso en esa ubicación exacta. Y nunca usaría GET para crear o modificar un recurso.
If the Request-URI does not point to an existing resource [...] the origin server *can* create the resource with that URI. Entonces, una implementación de PUT que se niegue a crear un recurso si no está presente sería correcta, ¿verdad? Si es así, ¿sucede esto en la práctica? ¿O las implementaciones generalmente también crean en PUT?
Solo semántica.
Se PUTsupone que un HTTP acepta el cuerpo de la solicitud y luego lo almacena en el recurso identificado por el URI.
Un HTTP POSTes más general. Se supone que inicia una acción en el servidor. Esa acción podría ser almacenar el cuerpo de la solicitud en el recurso identificado por el URI, o podría ser un URI diferente, o podría ser una acción diferente.
PUT es como cargar un archivo. Un put a un URI afecta exactamente ese URI. Una POST a un URI podría tener algún efecto.
Para dar ejemplos de recursos de estilo REST:
"POST / books" con un montón de información del libro podría crear un nuevo libro y responder con la nueva URL que identifica ese libro: "/ books / 5".
"PUT / books / 5" tendría que crear un nuevo libro con la identificación de 5, o reemplazar el libro existente con la ID 5.
En un estilo sin recursos, POST se puede usar para casi cualquier cosa que tenga un efecto secundario. Otra diferencia es que PUT debe ser idempotente: múltiples PUT de los mismos datos a la misma URL deben estar bien, mientras que múltiples POST pueden crear múltiples objetos o lo que sea que haga su acción POST.
PUT se entiende como un método para "subir" cosas a un URI particular, o sobrescribir lo que ya está en ese URI.
POST, por otro lado, es una forma de enviar datos RELACIONADOS con un URI dado.
Consulte el RFC de HTTP
Hasta donde sé, PUT se usa principalmente para actualizar los registros.
POST: para crear un documento o cualquier otro recurso
PUT: para actualizar el documento creado o cualquier otro recurso.
Pero para ser claro en ese PUT, generalmente 'Reemplaza' el registro existente si está allí y crea si no está allí.
Otros ya han publicado excelentes respuestas, solo quería agregar que con la mayoría de los lenguajes, marcos y casos de uso, se ocupará de POST mucho, mucho más a menudo que PUT. Hasta el punto en que PUT, DELETE, etc. son básicamente preguntas de trivia.
Por favor, consulte: http://zacharyvoase.com/2009/07/03/http-post-put-diff/
Últimamente me ha molestado bastante una idea errónea popular de los desarrolladores web de que se utiliza un POST para crear un recurso y un PUT para actualizar / cambiar uno.
Si echa un vistazo a la página 55 del RFC 2616 (“Protocolo de transferencia de hipertexto - HTTP / 1.1”), Sección 9.6 (“PUT”), verá para qué sirve realmente PUT:
El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud proporcionado.
También hay un párrafo útil para explicar la diferencia entre POST y PUT:
La diferencia fundamental entre las solicitudes POST y PUT se refleja en el significado diferente del Request-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad adjunta. Ese recurso podría ser un proceso de aceptación de datos, una puerta de enlace a algún otro protocolo o una entidad separada que acepte anotaciones. Por el contrario, el URI en una solicitud PUT identifica la entidad adjunta a la solicitud: el agente de usuario sabe a qué se destina el URI y el servidor NO DEBE intentar aplicar la solicitud a otro recurso.
No menciona nada sobre la diferencia entre actualizar / crear, porque de eso no se trata. Se trata de la diferencia entre esto:
obj.set_attribute(value) # A POST request.
Y esto:
obj.attribute = value # A PUT request.
Entonces, por favor, detengan la propagación de este concepto erróneo popular. Lee tus RFC.
Una POST se considera algo así como un método de tipo de fábrica. Incluye datos para crear lo que desea y lo que esté al otro lado sabe qué hacer con él. Un PUT se usa para actualizar los datos existentes en una URL determinada, o para crear algo nuevo cuando se sabe cuál será el URI y no existe (a diferencia de una POST que creará algo y devolverá una URL a si es necesario)
REST le pide a los desarrolladores que usen métodos HTTP explícitamente y de manera consistente con la definición del protocolo. Este principio de diseño REST básico establece un mapeo uno a uno entre las operaciones de creación, lectura, actualización y eliminación (CRUD) y los métodos HTTP. De acuerdo con este mapeo:
• Para crear un recurso en el servidor, use POST.
• Para recuperar un recurso, use GET.
• Para cambiar el estado de un recurso o actualizarlo, use PUT.
• Para eliminar o eliminar un recurso, use DELETE.
Más información: Servicios web RESTful: conceptos básicos de IBM
Debería ser bastante sencillo cuándo usar uno u otro, pero las palabras complejas son una fuente de confusión para muchos de nosotros.
Úselo PUTcuando desee modificar un recurso singular que ya forma parte de la colección de recursos. PUTreemplaza el recurso en su totalidad. Ejemplo:PUT /resources/:resourceId
Nota al margen: se usa PATCHsi desea actualizar una parte del recurso.
POSTcuando desee agregar un recurso secundario en una colección de recursos. POST => /resourcesPUTpara operaciones de ACTUALIZACIÓN .POSTpara operaciones CREATE .GET / empresa / informes => Obtener todos los informes
GET / empresa / informes / {id} => Obtener la información del informe identificada por "id"
POST / empresa / informes => Crear un nuevo informe
PUT / empresa / informes / {id} => Actualizar el información del informe identificada por "id"
PATCH / empresa / informes / {id} => Actualizar una parte de la información del informe identificada por "id"
DELETE / empresa / informes / {id} => Eliminar informe por "id"
La diferencia entre POST y PUT es que PUT es idempotente, lo que significa que llamar a la misma solicitud PUT varias veces siempre producirá el mismo resultado (eso no es un efecto secundario), mientras que llamar a una solicitud POST repetidamente puede tener ( adicional) efectos secundarios de crear el mismo recurso varias veces.
GET : Las solicitudes que utilizan GET solo recuperan datos, es decir, solicitan una representación del recurso especificado
POST: Envía datos al servidor para crear un recurso. El tipo del cuerpo de la solicitud se indica mediante el encabezado Content-Type. A menudo causa un cambio en el estado o efectos secundarios en el servidor
PUT : Crea un nuevo recurso o reemplaza una representación del recurso de destino con la carga útil de la solicitud
PATCH : Se utiliza para aplicar modificaciones parciales a un recurso
DELETE : Elimina el recurso especificado
TRACE : Realiza una prueba de bucle de mensajes a lo largo de la ruta al recurso de destino, proporcionando un mecanismo de depuración útil
OPTIONS : Se utiliza para describir las opciones de comunicación para el recurso de destino, el cliente puede especificar una URL para el método OPTIONS o un asterisco (*) para referirse a todo el servidor.
HEAD : Solicita una respuesta idéntica a la de una solicitud GET, pero sin el cuerpo de respuesta
CONNECT : Establece un túnel para el servidor identificado por el recurso de destino, se puede utilizar para acceder a sitios web que usan SSL (HTTPS)
Uso REST-ful
POST se usa para crear un nuevo recurso y luego devuelve el recurso URI
EX
REQUEST : POST ..../books
{
"book":"booName",
"author":"authorName"
}
Esta llamada puede crear un nuevo libro y devolver ese libro URI
Response ...THE-NEW-RESOURCE-URI/books/5
PUT se usa para reemplazar un recurso, si ese recurso existe, simplemente actualícelo, pero si ese recurso no existe, créelo,
REQUEST : PUT ..../books/5
{
"book":"booName",
"author":"authorName"
}
Con PUTconocemos el identificador de recurso, pero POSTdevolveremos el nuevo identificador de recurso
Uso no REST-ful
POST se usa para iniciar una acción en el lado del servidor, esta acción puede o no crear un recurso, pero esta acción tendrá efectos secundarios siempre cambiará algo en el servidor
PUT se usa para colocar o reemplazar contenido literal en una URL específica
Otra diferencia en los estilos REST-ful y no REST-ful
POST es una operación no idempotente: provocará algunos cambios si se ejecuta varias veces con la misma solicitud.
PUT Operación idempotente: no tendrá efectos secundarios si se ejecuta varias veces con la misma solicitud.
Vale la pena mencionar que POSTestá sujeto a algunos ataques comunes de falsificación de solicitudes entre sitios (CSRF) mientras PUTque no lo está.
El CSRF a continuación no es posiblePUT cuando la víctima visita attackersite.com.
El efecto del ataque es que la víctima sin querer borra un usuario sólo porque (la víctima) fue iniciado una sesión como adminel target.site.com, antes de visitar attackersite.com:
Solicitud normal (se envían cookies): ( PUTno es un valor de atributo compatible)
Código en attackersite.com:
<form id="myform" method="post" action="http://target.site.com/deleteUser" >
<input type="hidden" name="userId" value="5">
</form>
<script>document.createElement('form').submit.call(document.getElementById('myform'));</script>
Solicitud XHR (se envían cookies): ( PUTactivaría una solicitud de verificación previa, cuya respuesta evitaría que el navegador solicite la deleteUserpágina)
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);
En palabras simples puedes decir:
1.HTTP Get: se utiliza para obtener uno o más elementos
2. Publicación HTTP: se utiliza para crear un elemento
3.HTTP Put: se utiliza para actualizar un elemento
4.HTTP Patch: se utiliza para actualizar parcialmente un elemento
5.HTTP Delete: se usa para eliminar un elemento
En realidad no hay otra diferencia que su título. En realidad, hay una diferencia básica entre GET y los demás. Con un método "GET" -Request, envía los datos en la línea de dirección url, que se separan primero con un signo de interrogación y luego con un signo &.
Pero con un método de solicitud "POST", no puede pasar datos a través de la URL, pero debe pasar los datos como un objeto en el llamado "cuerpo" de la solicitud. En el lado del servidor, debe leer el cuerpo del contenido recibido para obtener los datos enviados. Pero, por otro lado, no hay posibilidad de enviar contenido en el cuerpo, cuando envía una solicitud "GET".
La afirmación de que "OBTENER" es solo para obtener datos y "POST" es para publicar datos, es absolutamente errónea. Nadie puede evitar que cree contenido nuevo, elimine contenido existente, edite contenido existente o haga lo que sea en el backend, en función de los datos, que se envían mediante la solicitud "GET" o la solicitud "POST". Y nadie puede evitar que codifique el back-end de una manera, que con una solicitud "POST", el cliente solicita algunos datos.
Con una solicitud, sin importar el método que utilice, llama a una URL y envía o no envía algunos datos para especificar, qué información desea pasar al servidor para atender su solicitud, y luego el cliente recibe una respuesta de el servidor. Los datos pueden contener lo que quiera enviar, el backend puede hacer lo que quiera con los datos y la respuesta puede contener cualquier información que desee poner allí.
Solo existen estos dos MÉTODOS BÁSICOS. OBTENER Y POSTAR. Pero es su estructura, lo que los hace diferentes y no lo que codifica en el backend. En el backend puedes codificar lo que quieras, con los datos recibidos. Pero con la solicitud "POST" debe enviar / recuperar los datos en el cuerpo y no en la línea de dirección url, y con una solicitud "GET", debe enviar / recuperar datos en la línea de dirección url y no en el cuerpo. Eso es todo.
Todos los demás métodos, como "PUT", "DELETE", etc., tienen la misma estructura que "POST".
El método POST se usa principalmente, si desea ocultar algo el contenido, porque lo que escriba en la línea de dirección url, se guardará en la memoria caché y un método GET es lo mismo que escribir una línea de dirección url con datos. Entonces, si desea enviar datos confidenciales, que no siempre son necesariamente nombre de usuario y contraseña, sino, por ejemplo, algunos identificadores o hashes, que no desea que se muestren en la línea de dirección URL, debe usar el método POST .
Además, la longitud de la dirección URL está limitada a 1024 símbolos, mientras que el método "POST" no está restringido. Entonces, si tiene una mayor cantidad de datos, es posible que no pueda enviarlos con una solicitud GET, pero deberá usar la solicitud POST. Así que este es también otro punto a favor de la solicitud POST.
Pero lidiar con la solicitud GET es mucho más fácil, cuando no tiene un texto complicado para enviar. De lo contrario, y este es otro punto a favor para el método POST, es que con el método GET debe codificar el texto con url para poder enviar algunos símbolos dentro del texto o incluso espacios. Pero con un método POST no tiene restricciones y su contenido no necesita ser cambiado o manipulado de ninguna manera.
Tanto PUT como POST son métodos de descanso.
PUT: si hacemos la misma solicitud dos veces usando PUT usando los mismos parámetros las dos veces, la segunda solicitud no tendrá ningún efecto. Esta es la razón por la cual PUT se usa generalmente para el escenario Actualización, llamar a Actualizar más de una vez con los mismos parámetros no hace nada más que la llamada inicial, por lo tanto, PUT es idempotente.
POST no es idempotente, por ejemplo, Create creará dos entradas separadas en el objetivo, por lo tanto, no es idempotente, por lo que CREATE se usa ampliamente en POST.
Hacer la misma llamada usando POST con los mismos parámetros cada vez hará que sucedan dos cosas diferentes, por lo tanto, por qué POST se usa comúnmente para el escenario Crear