Nuestros desarrolladores estrellas agotaron sus reservas de café, investigando día y noche por la solución, hasta que Sergio halló la respuesta en Bitbucket por lo tanto hoy la compartimos contigo.
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 HTTP 1.1 RFC para PUT
PUBLICACIÓN 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 son almacenable en caché siempre que el servidor establezca los encabezados Cache-Control y Expires apropiados.
El HTTP RFC oficial especifica que POST es:
- Anotación de los 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;
- 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 mismo explica la diferencia principal:
La diferencia fundamental entre las solicitudes POST y PUT se refleja en el diferente significado de 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 con 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 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
createdoreplacedcon 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:
Una de las ventajas de REST ROA frente a SOAP es que, al utilizar 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ía GET para crear o modificar un recurso.
Solo semántica.
un HTTP PUT se supone que debe aceptar el cuerpo de la solicitud y luego almacenarlo 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.
PONER es me gusta una carga de archivos. Un put a un URI afecta exactamente a ese URI. Un 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 identificación de 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 múltiples objetos o lo que sea que sea su POST la acción lo hace.
Te mostramos comentarios y puntuaciones
Si estás de acuerdo, tienes la opción de dejar una crónica acerca de qué te ha impresionado de este ensayo.