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

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

preguntado el 20 de septiembre de 08 a las 04:09

¿Responde esto a tu pregunta? PUT vs. POST en REST -

18 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 se pueden almacenar en caché.

Ubicación RFC HTTP 1.1 para PUT

POST HTTP:

POST envía datos a un URI específico y espera que el recurso en ese URI maneje la solicitud. En este punto, el servidor web 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 están almacenable en caché siempre que el servidor establezca los encabezados Cache-Control y Expires adecuados.

El RFC HTTP oficial especifica que POST es:

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

Ubicación RFC HTTP 1.1 para POST

Diferencia entre POST y PUT:

El RFC en sí mismo explica la diferencia principal:

La diferencia fundamental entre las solicitudes POST y PUT se refleja 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 entrada 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 se pretende 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 (Movido permanentemente); el agente de usuario PUEDE entonces tomar su propia decisión con respecto a si redirigir o no la solicitud.

Además, y de forma un poco más concisa, RFC 7231 Sección 4.3.4 PUT estados (énfasis agregado),

4.3.4. PONER

El método PUT solicita que el estado del recurso de destino sea created or replaced con el estado definido por la representación incluida en la carga útil del mensaje de solicitud.

Usando el método correcto, aparte de lo que no está relacionado:

Un beneficio de RESTO ROA vs SOAP es que cuando se usa 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.

respondido 13 nov., 19:04

Leí en las especificaciones que 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 niega 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 se crean en PUT? - houcros

alguna excepción adicional que hace que la diferencia sea muy clara se encuentra en la siguiente URL: dzone.com/articles/put-vs-post - Ashish Shetkar

Lo que no entiendo es cómo implementar la idempotencia de PUT. en general, la mayoría de las API utilizarán la generación automática de un ID en caso de crear un nuevo recurso. y en PUT, debe crear un recurso si no existe, pero use la ID especificada en el URI, pero ¿cómo puede hacerlo si el método de generación de ID está configurado para ser automático? - Roni Axelrad

En pocas palabras: el URI en un PUBLICAR solicitud identifica el recurso que manejará la entidad adjunta. El URI en un PUT solicitud identifica la propia entidad. - Drazen Bjelovuk

Las respuestas al método POST no se pueden almacenar en caché, A MENOS QUE la respuesta incluya los campos de encabezado Cache-Control o Expires apropiados - NattyC

Solo semántica.

Un HTTP PUT se supone que 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 una carga de archivo. Una puesta a un URI afecta exactamente a ese URI. Un POST a un URI podría tener algún efecto.

Respondido el 17 de Septiembre de 15 a las 14:09

Aquello que implica una determinada función puede que en realidad no ... taylormac

Para dar ejemplos de recursos de estilo REST:

POST /books con un montón de información del libro puede crear un libro nuevo 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 5 o reemplazar el libro existente con la identificación 5.

En 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últiple PUTs de los mismos datos a la misma URL debería estar bien, mientras que múltiples POSTs podría crear varios objetos o lo que sea que sea su POST la acción lo hace.

Respondido 13 Feb 21, 21:02

Hola Bhollis, ¿Qué pasará si uso POST / books / 5? ¿arrojará recurso no encontrado? - changan

Siento que la idempotencia es la diferencia más importante y distintiva entre PUT y POST - martín andersson

Hola ChanGan, aquí hay una explicación que Wikipedia da sobre su caso "POST / books / 5": "No se usa generalmente. Trate al miembro al que se dirige como una colección por derecho propio y cree una nueva entrada en ella". - rdiachenko

esta respuesta da la impresión de que PUT y POST se pueden definir en el mismo recurso, sin embargo, la otra diferencia junto a la idempotencia es quién controla el espacio de ID. En PUT, el usuario controla el espacio de ID creando recursos con un ID específico. En POST, el servidor devuelve la ID a la que el usuario debe hacer referencia en llamadas posteriores como GET. Lo anterior es extraño porque es una mezcla de ambos. - Tommy

  1. : Recupera datos del servidor. No debería tener ningún otro efecto.
  2. PUT: Reemplaza el recurso de destino con la carga útil de la solicitud. Puede usarse para actualizar o crear nuevos recursos.
  3. PARCHE: Similar a PUT, pero se usa para actualizar solo ciertos campos dentro de un recurso existente.
  4. PUBLICAR: Realiza un procesamiento específico de recursos en la carga útil. Se puede usar para diferentes acciones, incluida la creación de un nuevo recurso, la carga de un archivo o el envío de un formulario web.
  5. BORRAR: Elimina datos del servidor.
  6. TRACE: Proporciona una forma de probar lo que recibe el servidor. Simplemente devuelve lo que se envió.
  7. OPCIONES: Permite a un cliente obtener 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 usa 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. CABEZA: Devuelve solo los encabezados de respuesta.
  9. CONECTAR: 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 un extremo a otro, por lo que los datos son ilegibles para un proxy.

Respondido 23 Jul 20, 11:07

mejor respuesta corta - vibraciones2006

¿CONNECT se activa antes de cada solicitud cuando se usa https? - variable

La información proporcionada sobre PUT y POST no es correcta en esta respuesta. PUT se puede utilizar para crear una nueva entidad, así como para actualizar una entidad existente. POST es más genérico y se puede usar para realizar una acción similar como en PUT o se puede usar para realizar cualquier otra acción también en la entidad entrante (con efectos secundarios) e idealmente, PUT debe ser idempotente donde POST puede o no ser idempotente - Ketan R

@KetanR Gracias por tu comentario. Actualicé la respuesta. - Dragón de Jonatán

PUT está pensado como un método para "subir" cosas a un URI en 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.

Consulta el HTTP RFC

Respondido el 20 de Septiembre de 08 a las 07:09

Hasta donde yo 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 claros en que PUT generalmente 'Reemplaza' el registro existente si está allí y crea si no está allí.

respondido 24 mar '15, 13:03

¿Qué es un récord en este contexto? La pregunta es sobre la solicitud HTTP. - Kishore

¿Qué haría POST si el documento / recurso ya está presente? ¿Lanzará un error o simplemente saldrá bien? - Aditya Pednekar

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

Respondido 14 Feb 21, 12:02

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

Últimamente me ha molestado bastante la idea errónea de los desarrolladores web de que se usa un POST para crear un recurso y que se usa 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á para qué sirve PUT:

El método PUT solicita que la entidad adjunta se almacene bajo el Request-URI 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 puede ser un proceso de aceptación de datos, una puerta de entrada 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 se pretende 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, detenga la propagación de este error popular. Lea sus RFC.

Respondido 11 ago 14, 18:08

Esto parece inútilmente grosero y pedante de una manera poco útil. En el ejemplo de un PUT que cita, la nueva entidad es, en una API RESTful, un registro 'nuevo' y accesible en esa ubicación. Es cuestionable si es una buena opción de diseño permitir que los submiembros sean así mutables (creo que no es ideal), pero incluso si lo fuera, estás usando una subespecie para atacar mucha información útil. La mayoría de las veces, la descripción, tal como se indica habitualmente, es una gran declaración del contenido del RFC, resumido, y una declaración de la práctica habitual. Además, no te hará daño ser cortés. - usuario de la herramienta

Esto no se puede votar lo suficiente. PUT no tiene lugar en una API REST. La mayoría de las veces, POST indica la semántica correcta. - beefster

No bien dicho, pero sí una interpretación precisa de las RFC. El mundo de los desarrolladores web es un pantano de desinformación, al parecer. - William T. Froggard

@Beefster No existe tal cosa como 'POST indica'. Najeebul hizo un gran punto aquí. ¿Cómo calcula lo que indica? excepto que solo lo usa porque siempre lo ha usado de esa manera desde el primer día que lo aprendió, pero realmente no sabe por qué debería usarlo en comparación con los demás. - mosia thabo

el enlace proporcionado no funciona - Tamsamani

Un POST se considera algo así como un método de tipo de fábrica. Incluyes datos con él para crear lo que quieres y lo que esté en el otro extremo sabe qué hacer con él. Un PUT se usa para actualizar los datos existentes en una URL determinada, o para crear algo nuevo cuando sabe cuál va a ser el URI y aún no existe (a diferencia de un POST que creará algo y devolverá una URL a si es necesario).

Respondido el 20 de Septiembre de 08 a las 07:09

Definir operaciones en términos de métodos HTTP

El protocolo HTTP define una serie de métodos que asignan un significado semántico a una solicitud. Los métodos HTTP comunes utilizados por la mayoría de las API web RESTful son:

recupera una representación del recurso en el URI especificado. El cuerpo del mensaje de respuesta contiene los detalles del recurso solicitado.

PUBLICAR crea un nuevo recurso en el URI especificado. El cuerpo del mensaje de solicitud proporciona los detalles del nuevo recurso. Tenga en cuenta que POST también se puede utilizar para desencadenar operaciones que en realidad no crean recursos.

PUT crea o reemplaza el recurso en el URI especificado. El cuerpo del mensaje de solicitud especifica el recurso que se creará o actualizará.

PARCHE realiza una actualización parcial de un recurso. El cuerpo de la solicitud especifica el conjunto de cambios que se aplicarán al recurso.

BORRAR elimina el recurso en el URI especificado.

El efecto de una solicitud específica debería depender de si el recurso es una colección o un artículo individual. La siguiente tabla resume las convenciones comunes adoptadas por la mayoría de las implementaciones RESTful utilizando el ejemplo de comercio electrónico. Es posible que no se implementen todas estas solicitudes; depende del escenario específico.

Recurso PUBLICAR PUT BORRAR
/clientes Crea un nuevo cliente Recuperar todos los clientes Actualización masiva de clientes Eliminar todos los clientes
/ clientes / 1 Error Recuperar los detalles del cliente 1 Actualice los detalles del cliente 1 si existe Eliminar cliente 1
/ clientes / 1 / pedidos Crear un nuevo pedido para el cliente 1 Recuperar todos los pedidos del cliente 1 Actualización masiva de pedidos para el cliente 1 Eliminar todos los pedidos del cliente 1

Las diferencias entre POST, PUT y PATCH pueden ser confusas.

A PUBLICAR la solicitud crea un recurso. El servidor asigna un URI para el nuevo recurso y devuelve ese URI al cliente. En el REST model, aplica con frecuencia POST solicitudes a colecciones. El nuevo recurso se agrega a la colección. A POST La solicitud también se puede utilizar para enviar datos para su procesamiento a un recurso existente, sin que se cree ningún recurso nuevo.

A PUT solicitud crea un recurso o actualiza un recurso existente. El cliente especifica el URI del recurso. El cuerpo de la solicitud contiene una representación completa del recurso. Si ya existe un recurso con este URI, se reemplaza. De lo contrario, se crea un nuevo recurso, si el servidor lo permite. PUT las solicitudes se aplican con mayor frecuencia a recursos que son elementos individuales, como un cliente específico, en lugar de colecciones. Un servidor puede admitir actualizaciones pero no creación a través de PUT. Ya sea para apoyar la creación a través de PUT depende de si el cliente puede asignar de manera significativa un URI a un recurso antes de que exista. Si no es así, utilice POST para crear recursos y PUT or PATCH actualizar.

A PARCHE la solicitud realiza una actualización parcial de un recurso existente. El cliente especifica el URI del recurso. El cuerpo de la solicitud especifica un conjunto de cambios para aplicar al recurso. Esto puede ser más eficiente que usar PUT, porque el cliente solo envía los cambios, no la representación completa del recurso. Técnicamente PATCH también puede crear un nuevo recurso (especificando un conjunto de actualizaciones a un recurso "nulo"), si el servidor lo admite.

PUT las solicitudes deben ser idempotentes. Si un cliente envía el mismo PUT solicitar varias veces, los resultados deben ser siempre los mismos (el mismo recurso se modificará con los mismos valores). POST and PATCH no se garantiza que las solicitudes sean idempotentes.

Respondido 13 Feb 21, 12:02

Creo que tienes PUT y POST al revés - beefster

No. PUT es para colocar contenido literal en una URL y rara vez tiene su lugar en una API REST. POST es más abstracto y cubre cualquier tipo de contenido añadido que no tenga la semántica de "Pon este archivo exacto en esta URL exacta". - beefster

−1 porque además de actualización, PUT también se utiliza para Para crear a objetivo recurso (el recurso identificado por el URI de solicitud), a diferencia de POST que no puede crear un recurso de destino porque no es una operación CRUD en los estados de los recursos (gestión de datos) sino una MODO DE PREPARACIÓN operación (cf. RFC 7231). El proceso puede crear un recurso pero diferente del recurso de destino, por lo que lo convierte en una operación CRUD. - maggyero

Debería ser bastante sencillo cuándo usar uno u otro, pero las redacciones complejas son una fuente de confusión para muchos de nosotros.

Cuándo usarlos:

  • Utilice las PUT cuando desee modificar un recurso singular que ya es parte de la colección de recursos. PUT reemplaza el recurso en su totalidad. Ejemplo: PUT /resources/:resourceId

    Nota al margen: Utilice las PATCH si desea actualizar una parte del recurso.


  • Utilice las POST cuando desee agregar un recurso secundario a una colección de recursos.
    Ejemplo: POST => /resources

En general:

  • Generalmente, en la práctica, utilice siempre PUT por ACTUALIZACIÓN operaciones.
  • Siempre usa POST por CREAR operaciones.

Ejemplo:

GET / empresa / informes => Obtenga todos los informes
GET / empresa / informes / {id} => Obtener la información del informe identificada por "id"
POST / empresa / informes => Crear un informe nuevo
PUT / empresa / informes / {id} => Actualizar la 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"

Respondido 21 Feb 20, 20:02

La diferencia entre POST y PUT es que PUT es idempotente, es decir, 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 ( adicionales) 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 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, lo que proporciona 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 al servidor identificado por el recurso de destino, se puede usar para acceder a sitios web que usan SSL (HTTPS)

Respondido 22 Oct 18, 20:10

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 libro nuevo 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 PUT conocemos el identificador del recurso, pero POST devolverá 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 utiliza 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: causará algunos cambios si se ejecuta varias veces con la misma solicitud.

PUT Es una operación idempotente: no tendrá efectos secundarios si se ejecuta varias veces con la misma solicitud.

Respondido 07 ago 19, 09:08

En palabras simples puedes decir:

1.HTTP Get: se usa 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 utiliza para eliminar un elemento

Respondido 18 Abr '20, 11:04

Vale la pena mencionar que POST está sujeto a algunos Ataques de falsificación de solicitudes entre sitios (CSRF) mientras PUT no lo es.

Los CSRF a continuación son no es posible con PUT cuando la victima visita attackersite.com.

Las efecto del ataque es que el la víctima elimina involuntariamente un usuario solo porque (la víctima) inició sesión como admin on target.site.com, antes de visitar attackersite.com:

Código malicioso activado attackersite.com:

Caso 1: Solicitud normal. salvado target.site.com Las cookies serán enviadas automáticamente por el navegador: (nota: soporte PUT solo, en el punto final, es más seguro porque no es un soporte <form> valor de atributo)

<!--deletes user with id 5-->
<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>

Caso 2: Solicitud XHR. salvado target.site.com Las cookies serán enviadas automáticamente por el navegador: (nota: soporte PUT solo, en el punto final, es más seguro porque un intento de enviar PUT desencadenaría una solicitud de verificación previa, cuya respuesta evitaría que el navegador solicite el deleteUser .

//deletes user with id 5
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target.site.com/deleteUser");
xhr.withCredentials=true;
xhr.send(["userId=5"]);

Referencia MDN : [..] A diferencia de las "solicitudes simples" (discutidas anteriormente), - [[Significa: POST / GET / HEAD]] -, para las solicitudes "preflight", el navegador envía primero una solicitud HTTP utilizando el método OPTIONS [.. ]

cors en acción : [..] Ciertos tipos de solicitudes, como DELETE o PUT, necesitan ir un paso más allá y solicitar el permiso del servidor antes de realizar la solicitud real [..] lo que se llama una solicitud de verificación previa [..]

Respondido el 19 de enero de 21 a las 00:01

En realidad, no hay otra diferencia que no sea su título. En realidad, existe una diferencia básica entre GET y los demás. Con un método "GET" -Request, envías los datos en la línea de dirección URL, que están separados primero por un signo de interrogación y luego por 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 "GET" es solo para obtener datos y "POST" es para publicar datos, es absolutamente incorrecta. Nadie puede impedirle crear contenido nuevo, eliminar contenido existente, editar contenido existente o hacer cualquier cosa en el backend, en función de los datos, que se envía mediante la solicitud "GET" o mediante la solicitud "POST". Y nadie puede evitar que codifiques el backend de una manera, que con un "POST" -Request, el cliente te pida algunos datos.

Con una solicitud, sin importar qué método use, 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 obtiene una respuesta el servidor. Los datos pueden contener lo que quieras enviar, el backend puede hacer lo que quiera con los datos y la respuesta puede contener cualquier información que quieras poner allí.

Solo existen estos dos MÉTODOS BÁSICOS. OBTENER y PUBLICAR. Pero es su estructura lo que los hace diferentes y no lo que codificas en el backend. En el backend puedes codificar lo que quieras, con los datos recibidos. Pero con la solicitud "POST" tienes que enviar / recuperar los datos en el cuerpo y no en la línea de dirección URL, y con una solicitud "GET", tienes que 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 un poco el contenido, porque lo que sea que escriba en la línea de direcciones URL, esto se guardará en la caché y un método GET es lo mismo que escribir una línea de direcciones URL con datos. Entonces, si desea enviar datos confidenciales, que no siempre son necesariamente el nombre de usuario y la contraseña, pero, por ejemplo, algunos identificadores o hash, que no desea que se muestren en la línea de dirección de URL, entonces debe usar el método POST .

Además, la longitud de la línea de direcciones URL está limitada a 1024 símbolos, mientras que el método "POST" no está restringido. Por lo tanto, si tiene una mayor cantidad de datos, es posible que no pueda enviarla 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 que enviar un texto complicado. De lo contrario, y este es otro punto a favor del método POST, es que con el método GET es necesario codificar el texto en 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.

Respondido el 08 de diciembre de 19 a las 17:12

Tanto PUT como POST son métodos de reposo.

PUT: si hacemos la misma solicitud dos veces usando PUT usando los mismos parámetros en ambas ocasiones, la segunda solicitud no tendrá ningún efecto. Esta es la razón por la que PUT se usa generalmente para el escenario de actualización, llamar a Update más de una vez con los mismos parámetros no hace nada más que la llamada inicial, por lo que PUT es idempotente.

POST no es idempotente, por ejemplo, Create creará dos entradas separadas en el objetivo, por lo que 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 que POST se usa comúnmente para el escenario Crear

Respondido el 14 de diciembre de 19 a las 11:12

Los métodos de solicitud GET, PUT y DELETE son CRUD (crear, leer, actualizar y eliminar) operaciones, es decir, operaciones de administración de datos, en el estado de un objetivo recurso (el identificado por el URI de solicitud):

  • OBTENER debería leer el estado del recurso de destino;
  • PONER debe Para crear or actualización el estado del recurso de destino;
  • ELIMINAR debe borrar el estado del recurso de destino.

El método de solicitud POST es una bestia diferente. No debe crear el estado del recurso de destino como PUT porque es un MODO DE PREPARACIÓN operación con un objetivo de nivel superior al CRUD (cf. RFC 7231, sección 4.3.3). El proceso puede crear un recurso pero diferente del objetivo recurso; de lo contrario, se debe usar el método de solicitud de objetivo de nivel inferior PUT, por lo que incluso en este caso eso no lo convierte en una operación CRUD.

La diferencia entre las operaciones CRUD (GET, PUT y DELETE en HTTP) y las operaciones no CRUD (POST en HTTP) es la diferencia entre tipos de datos abstractos y objetos que Alan Kay estaba haciendo hincapié en la mayoría de sus charlas y en su artículo de ACM La historia temprana de Smalltalk:

Lo que obtuve de Simula fue que ahora se pueden reemplazar las vinculaciones y las asignaciones por metas. Lo último que deseaba que hiciera cualquier programador es meterse con el estado interno, incluso si se presenta en sentido figurado. En cambio, los objetos deben presentarse como sitios de comportamientos de nivel superior más apropiados para su uso como componentes dinámicos.

[…] Es lamentable que gran parte de lo que se llama "programación orientada a objetos" en la actualidad sea simplemente programación de estilo antiguo con construcciones más sofisticadas. Muchos programas están cargados con operaciones de "estilo de asignación" que ahora se realizan mediante procedimientos adjuntos más costosos.

[…] Las declaraciones de tareas, incluso las abstractas, expresan metas de muy bajo nivel, y se necesitarán más para hacer algo. […] Otra forma de pensar en todo esto es: aunque la vinculación tardía de las asignaciones de almacenamiento automático no hace nada que un programador no pueda hacer, su presencia conduce a un código más simple y más poderoso. OOP es una estrategia de vinculación tardía para muchas cosas y todas juntas evitan la fragilidad y la explosión de tamaño mucho más tiempo que las metodologías más antiguas.

Respondido el 04 de diciembre de 20 a las 20:12

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.