¿Cuál es la diferencia entre un POST y PUT HTTP REQUEST?

Question

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

Answer 1

HTTP PUT:

PUT pone 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 son almacenables.

HTTP 1.1 RFC location for PUT

HTTP POST:

POST envía los datos a un URI específico y espera que el recurso en ese URI para manejar la petición. 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 son almacenables en caché siempre que el servidor establezca los encabezados Cache-Control y Expires adecuados.

El RFC oficial HTTP POST para ser especifica:

• anotación de los recursos existentes;
• Publicar un mensaje en un tablero de anuncios, un grupo de noticias, una lista de correo, o un grupo similar de artículos;
• Proporcionando un bloque de datos, como el resultado de enviar un formulario , a un proceso de manejo de datos;
• Extensión de una base de datos a través de una operación de adición.

HTTP 1.1 RFC location for POST

Diferencia entre POST y PUT:

El RFC sí explica la diferencia central:

La diferencia fundamental entre el poste y PUT solicitudes se refleja en el significado diferente de Request-URI. El URI en una solicitud POST identifica el recurso que manejará la entidad incluida . Ese recurso podría ser un proceso que acepta datos, una puerta de enlace a algún otro protocolo , o una entidad separada que acepta anotaciones. Por el contrario, la URI en una solicitud PUT identifica la entidad adjunta a la solicitud - el agente de usuario sabe lo URI es previsto y el servidor DEBE NO intento de aplicar la solicitud a alguna otra recursos. Si el servidor desea que la solicitud se aplique a un URI diferente , DEBE enviar una respuesta 301 (Movido permanentemente); el agente de usuario PUEDE luego hacer su propia decisión con respecto a si se debe redirigir o no la solicitud.

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

Un beneficio de REST ROA vs jabón es que cuando se utiliza HTTP REST ROA, se fomenta el uso adecuado de los verbos HTTP/métodos. Entonces, por ejemplo, solo usaría PUT cuando quiera crear un recurso en esa ubicación exacta. Y nunca usarías GET para crear o modificar un recurso.

Answer 2

PUT se entiende como un método para "cargar" 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 the HTTP RFC

Answer 3

Sólo semántica.

Se supone que 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 debe iniciar 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 cargando un archivo. Un puesto en un URI afecta exactamente ese URI. Un POST a un URI podría tener algún efecto.

Answer 4

Un POST se considera 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 utiliza para actualizar datos existentes en una URL determinada, o para crear algo nuevo cuando usted sabe lo que será el URI y no existe ya (a diferencia de un POST que creará algo y devolverá una URL a si es necesario).

Answer 5

Para dar ejemplos de recursos de estilo REST:

"POST/libros" con un montón de información del libro podría crear un nuevo libro, y responder con la nueva URL de la identificación de ese libro: "/ libros/5" .

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

En el estilo no-recurso, POST se pueden utilizar para casi sobre 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 deberían estar bien, mientras que múltiples POST pueden crear múltiples objetos o lo que sea que haga su acción POST.

Answer 6

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

Answer 7

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

1. Post - Para crear el documento o cualquier otro recurso

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

Pero tener claro que ponen normalmente 'sustituye' el registro existente si está allí y crea si no existe ..

Answer 8

Por favor, vea: http://zacharyvoase.com/2009/07/03/http-post-put-diff/

He estado recibiendo bastante molesto últimamente por una idea errónea popular de los desarrolladores web de que se utiliza un POST para crear un recurso, y se usa un PUT para actualizar/cambiar uno.

Si se echa un vistazo a la página 55 del RFC 2616 (“Protocolo de Transferencia de Hipertexto - HTTP/1.1”), Section 9.6 (“PUT”), verá lo que es en realidad PUT para:

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

También hay un párrafo muy útil para explicar la diferencia entre la POST y PUT:

La diferencia fundamental entre el POST y PUT solicitudes 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 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. Por el contrario, el URI en una solicitud PUT identifica la entidad adjunta a 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.

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. 

Así que por favor, detener la propagación de esta creencia popular. Lee tus RFC.

Answer 9

1) GET: - Se usa cuando el cliente solicita un recurso en el servidor web.

2) CABEZA: Se usa cuando el cliente solicita información sobre un recurso pero no solicita el recurso en sí.

3) POST: Se usa cuando el cliente está enviando información o datos al servidor, por ejemplo, completando un formulario en línea (es decir, envía una gran cantidad de datos complejos al servidor web).

4) PUT: - Se usa cuando el cliente está enviando un documento de reemplazo o cargando un nuevo documento al servidor web bajo la URL de solicitud.

5) ELIMINAR: - Se usa cuando el cliente intenta eliminar un documento del servidor web, identificado por la URL de solicitud.

6) RASTREO: - Se usa cuando el cliente solicita a los servidores proxy intermedios o servidores intermedios que cambian la solicitud para que se anuncien.

7) OPCIONES: - Se usa cuando el cliente desea determinar otros métodos disponibles para recuperar o procesar un documento en el servidor web.

8) CONNECT: Se usa cuando el cliente desea establecer una conexión transparente con un host remoto, generalmente para facilitar la comunicación encriptada mediante SSL (HTTPS) a través de un proxy HTTP.

Answer 10

Según RFC, la diferencia entre PUT y POST se encuentra 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. Por lo tanto, POST /v1/coffees/orders significa crear un nuevo recurso y devolver un identificador para describir el recurso. Por el contrario, 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 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.

Answer 11

RESTO pide a los desarrolladores utilizar métodos HTTP de forma explícita y de una manera que es consistente con la definición protocolo. Este principio básico de diseño REST 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, utilice ELIMINAR.

Más información: RESTful Web services: The basics from IBM

Answer 12

La diferencia entre PUT y POSTAL es la siguiente:

El cliente utiliza PUT cuando es el encargado de decidir qué URI del nuevo recurso debería tener.

El cliente usa POST cuando el servidor está a cargo de decidir qué URI debe tener el nuevo recurso.

Answer 13

1. OBTENER: 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 utiliza al cargar un archivo o enviar un formulario web.
3. PUT: similar a POST, pero se usa para reemplazar una entidad existente.
4. PARCHE: Similar a PUT, pero se usa para actualizar solo ciertos campos dentro de una entidad existente.
5. ELIMINAR: Elimina datos del servidor.
6. TRACE: 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 acerca de los encabezados personalizados.
8. CABEZA: Devuelve solo los encabezados de respuesta.
9. CONNECT: Usado 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 encriptada de extremo a extremo, por lo que los datos no se pueden leer en un proxy.