¿Cuál es la diferencia entre una POST y una SOLICITUD HTTP PUT?

Ambos parecen estar enviando datos al servidor dentro del cuerpo, entonces, ¿qué los hace diferentes?

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:

• Anotación de recursos existentes;
• Publicar un mensaje en un tablón de anuncios, grupo de noticias, lista de correo o grupo similar de artículos;
• Proporcionar un bloque de datos, como el resultado de enviar un formulario, a un proceso de manejo de datos;
• Extender una base de datos a través de una operación de agregar.

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 createdo replacedcon 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.

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.

1. GET : recupera datos del servidor. No debería tener otro efecto.
2. POST : envía datos al servidor para crear una nueva entidad. A menudo se usa al cargar un archivo o enviar un formulario web.
3. PUT : similar a POST, pero se usa para reemplazar una entidad existente.
4. PATCH : similar a PUT, pero se usa para actualizar solo ciertos campos dentro de una entidad existente.
5. BORRAR : elimina datos del servidor.
6. RASTREO : proporciona una forma de probar qué servidor recibe. Simplemente devuelve lo que se envió.
7. OPCIONES : permite que un cliente obtenga información sobre los métodos de solicitud admitidos por un servicio. El encabezado de respuesta relevante es Permitir con métodos compatibles. También se utiliza en CORS como solicitud de verificación previa para informar al servidor sobre el método de solicitud real y preguntar sobre encabezados personalizados.
8. HEAD : solo devuelve los encabezados de respuesta.
9. CONECTAR : Utilizado por el navegador cuando sabe que habla con un proxy y el URI final comienza con https: //. La intención de CONNECT es permitir una sesión TLS cifrada de extremo a extremo, de modo que los datos no se puedan leer en un proxy.

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.

1. POST: para crear un documento o cualquier otro recurso

2. 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.

Cuando usarlos:

• Ú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.

• Úselo POSTcuando desee agregar un recurso secundario en una colección de recursos.
  Ejemplo:POST => /resources

En general:

• Generalmente, en la práctica, use siempre PUTpara operaciones de ACTUALIZACIÓN .
• Úselo siempre POSTpara operaciones CREATE .

Ejemplo:

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