¿Cuál es la diferencia entre una SOLICITUD POST y PUT HTTP?
Ambos parecen estar enviando datos al servidor dentro del cuerpo, entonces, ¿qué los hace diferentes?
PUESTA HTTP:
PUT coloca un archivo o recurso en un URI específico y exactamente en ese URI. Si ya existe 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 HTTP 1.1 RFC para PUT
ENVÍO 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 se pueden almacenar en caché siempre que el servidor establezca los encabezados Cache-Control y Expires apropiados.
El RFC HTTP oficial especifica que POST sea:
- Anotación de recursos existentes;
- Publicar un mensaje en un tablero 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;
- Ampliar una base de datos mediante una operación de adición.
Ubicación HTTP 1.1 RFC para POST
Diferencia entre POST y PUT:
El propio RFC explica la diferencia principal:
La diferencia fundamental entre las solicitudes POST y PUT se refleja en el diferente significado 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 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 sobre si redirigir o no la solicitud.
Además, y de manera un poco más concisa, RFC 7231 Sección 4.3.4 PUT establece (énfasis agregado),
4.3.4. PONER
El método PUT solicita que el estado del recurso de destino sea
createdoreplacedtenga el estado definido por la representación incluida en la carga útil del mensaje de solicitud.
Usando el método correcto, aparte de lo relacionado:
Un beneficio de REST ROA frente a SOAP es que cuando se utiliza 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 usarías GET para crear o modificar un recurso.
Sólo semántica.
Se supone que un HTTP PUTacepta 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 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 cargar un archivo. Una transferencia a un URI afecta exactamente a ese URI. Una POST a un URI podría tener algún efecto.
Para dar ejemplos de recursos de estilo REST:
POST /bookscon mucha información del libro, puede crear un libro nuevo y responder con la nueva URL que identifica ese libro: /books/5.
PUT /books/5Tendría que crear un nuevo libro con el ID 5 o reemplazar el libro existente con el ID 5.
En un estilo sin recursos, POSTse puede utilizar para casi cualquier cosa que tenga un efecto secundario. Otra diferencia es que PUTdebería ser idempotente: varios PUTmensajes de correo electrónico de los mismos datos en la misma URL deberían estar bien, mientras que varios POSTmensajes de correo electrónico pueden crear múltiples objetos o lo que sea que POSThaga su acción.
- GET : recupera datos del servidor. No debería tener ningún otro efecto.
- PUT : reemplaza el recurso de destino con la carga útil de la solicitud. Se puede utilizar para actualizar o crear un nuevo recurso.
- PATCH : Similar a PUT, pero se usa para actualizar solo ciertos campos dentro de un recurso existente.
- POST : realiza un procesamiento específico de recursos en la carga útil. Se puede utilizar para diferentes acciones, incluida la creación de un nuevo recurso, la carga de un archivo o el envío de un formulario web.
- DELETE : Elimina datos del servidor.
- TRACE : proporciona una forma de probar lo que recibe el servidor. Simplemente devuelve lo enviado.
- 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 admitidos. 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.
- HEAD : Devuelve sólo los encabezados de respuesta.
- CONNECT : Utilizado por el navegador cuando sabe que está hablando con un proxy y el URI final comienza con
https://. La intención de CONNECT es permitir sesiones TLS cifradas de extremo a extremo, de modo que los datos no puedan leerse para un proxy.
