respuestas - solicitudes http

¿Cuál es la diferencia entre un POST y un PUT HTTP SOLICITUD? (12)

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

GET : Recupera datos del servidor. No debería tener ningún otro efecto.
POST : envía datos al servidor para crear una nueva entidad. A menudo se utiliza al cargar un archivo o enviar un formulario web.
PUT : similar a POST, pero se usa para reemplazar una entidad existente.
PARCHE : similar a PUT, pero usado para actualizar solo ciertos campos dentro de una entidad existente.
ELIMINAR : Elimina datos del servidor.
RASTREO : proporciona una manera de probar lo que recibe el servidor. Simplemente devuelve lo que fue enviado.
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 los encabezados personalizados.
HEAD : Devuelve solo los encabezados de respuesta.
CONECTAR : El navegador lo usa cuando sabe que habla con un proxy y el URI final comienza con https: //. La intención de CONECTAR es permitir una sesión TLS cifrada de extremo a extremo, por lo que los datos son ilegibles para un proxy.

Consulte: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

Últimamente, los desarrolladores web me han estado molestando bastante por la idea errónea de que un POST se utiliza para crear un recurso y un PUT para actualizar / cambiar uno.

Si echa un vistazo a la página 55 de RFC 2616 (“Protocolo de transferencia de hipertexto - HTTP / 1.1”), Sección 9.6 (“PUT”), verá qué PUT es en realidad para:

El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud suministrado.

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 de la solicitud-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. En contraste, el URI en una solicitud PUT identifica la entidad incluida en la solicitud: el agente de usuario sabe a qué se destina el URI y el servidor NO DEBE intentar aplicar la solicitud a algún otro recurso.

No menciona nada sobre la diferencia entre actualizar / crear, porque no se trata de eso. Se trata de la diferencia entre esto:

obj.set_attribute(value) # A POST request.

Y esto:

obj.attribute = value # A PUT request.

Así que por favor, detén la propagación de este error popular. Lee tus RFC.

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 (que no es un efecto secundario), mientras que, por otro lado, llamar a una solicitud POST repetidamente puede tener ( adicional) efectos secundarios de crear el mismo recurso varias veces.

GET : las solicitudes que usan 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 de cuerpo de la solicitud se indica mediante el encabezado Content-Type. A menudo provoca un cambio de 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 solicitud

PATCH : Se utiliza para aplicar modificaciones parciales a un recurso.

DELETE : Borra el recurso especificado

TRACE : realiza una prueba de bucle de retorno de mensajes a lo largo de la ruta al recurso de destino, lo que proporciona un mecanismo de depuración útil

OPTIONS : se usa para describir las opciones de comunicación para el recurso objetivo, el cliente puede especificar una URL para el método OPCIONES 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 hacia el servidor identificado por el recurso objetivo, se puede usar para acceder a sitios web que usan SSL (HTTPS)

Otros ya han publicado excelentes respuestas, solo quería agregar que con la mayoría de los lenguajes, marcos y casos de uso, usted estará lidiando con POST mucho, mucho más a menudo que PUT. Hasta el punto donde PUT, DELETE, etc. son básicamente preguntas de trivia.

PUT se entiende como un método para "cargar" cosas en 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 determinado.

Consulte la RFC HTTP

Para dar ejemplos de recursos de estilo REST:

"POST / books" con un montón de información del libro puede crear un nuevo libro, y responder con la nueva URL que identifica ese libro: "/ books / 5".

"PUT / books / 5" tendría que crear un libro nuevo con el ID de 5 o reemplazar el libro existente con ID 5.

En el estilo sin recursos, POST puede usarse para casi cualquier cosa que tenga un efecto secundario. Otra diferencia es que PUT debe ser idempotente: múltiples PUT de los mismos datos en la misma URL deben estar bien, cuando múltiples POST pueden crear múltiples objetos o lo que sea que haga su acción POST.

Por lo que sé, PUT se utiliza principalmente para actualizar los registros.

POST - Para crear documento o cualquier otro recurso.
PUT - Para actualizar el documento creado o cualquier otro recurso.

Pero para ser claro, PUT usualmente ''Reemplaza'' el registro existente si está allí y crea si no está ahí.

REST les pide a los desarrolladores que usen métodos HTTP explícitamente y de una manera que sea consistente con la definición del protocolo. Este principio básico de diseño de REST establece una asignación uno a uno entre las operaciones de creación, lectura, actualización y eliminación (CRUD) y los métodos HTTP. Según 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: los conceptos básicos de IBM

Sólo semántica.

Se supone que un HTTP PUT acepta el cuerpo de la solicitud y luego lo almacena en el recurso identificado por el URI.

Un HTTP POST es 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 una carga de archivos. Un puesto en un URI afecta exactamente a ese URI. Un POST a un URI podría tener algún efecto en absoluto.

Según RFC , la diferencia entre PUT y POST está en el URI de solicitud. El URI identificado por POST define la entidad que manejará la solicitud POST. El URI en la solicitud PUT incluye la entidad en la solicitud. Entonces, POST /v1/coffees/orders significa crear un nuevo recurso y devolver un identificador para describir el recurso. En contraste, PUT /v1/coffees/orders/1234 significa actualizar un recurso identificado por " 1234 " si existe; De lo contrario, cree un nuevo pedido y use el URI de orders/1234 para identificarlo.

PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.

Un POST se considera algo de un método de tipo de fábrica. Incluyes datos con él para crear lo que quieres y lo que sea que esté en el 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 un POST que creará algo y devolverá una URL a si es necesario).

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 idempotent , pero, paradójicamente, las respuestas PUT no se pueden almacenar en caché.

Ubicación de 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 idempotent , 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 POST para ser:

Anotación de los recursos existentes;
Publicación de un mensaje en un tablón de anuncios, grupo de noticias, lista de correo o grupo de artículos similares;
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 anexión.

Ubicación de HTTP 1.1 RFC para POST

Diferencia entre POST y PUT:

El propio RFC explica la diferencia de núcleo:

La diferencia fundamental entre las solicitudes POST y PUT se refleja en el significado diferente de la solicitud-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. En contraste, el URI en una solicitud PUT identifica la entidad incluida en la solicitud: el agente de usuario sabe a qué se destina el URI y el servidor NO DEBE intentar aplicar la solicitud a algún 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 entonces tomar su propia decisión sobre si redirigir o no la solicitud.

Usando el método correcto, sin relación aparte:

Uno de los beneficios de REST ROA vs SOAP es que al usar HTTP REST ROA, 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 utilizarías GET para crear o modificar un recurso.