¿Cuál es la diferencia entre POST y PUT en HTTP?
Análisis de información de antecedentes:
Según RFC 2616, § 9.5 , POSTse utiliza para crear un recurso:
El método POST se utiliza para solicitar que el servidor de origen acepte la entidad incluida en la solicitud como un nuevo subordinado del recurso identificado por el URI de solicitud en la línea de solicitud.
Según RFC 2616, § 9.6 , PUTse utiliza para crear o reemplazar un recurso:
El método PUT solicita que la entidad adjunta se almacene bajo el URI de solicitud proporcionado. Si el URI de solicitud se refiere a un recurso ya existente, la entidad adjunta DEBE considerarse como una versión modificada de la que reside en el servidor de origen. Si el URI de solicitud no apunta a un recurso existente y el agente de usuario solicitante puede definir ese URI como un nuevo recurso, el servidor de origen puede crear el recurso con ese URI.
Mi pregunta:
Entonces, ¿qué método HTTP debería usarse para crear un recurso? ¿O deberían apoyarse ambos?
En general:
Tanto PUT como POST se pueden utilizar para crear.
Tienes que preguntar "¿sobre qué estás realizando la acción?" para distinguir qué deberías usar. Supongamos que está diseñando una API para hacer preguntas. Si desea utilizar POST, debe hacerlo con una lista de preguntas. Si desea utilizar PUT, debe hacerlo con una pregunta en particular.
Genial, se pueden usar ambos, entonces, ¿cuál debo usar en mi diseño RESTful?
No es necesario admitir tanto PUT como POST.
El que utilices depende de ti. Pero recuerde usar el correcto dependiendo del objeto al que haga referencia en la solicitud.
Algunas consideraciones:
- ¿Nombra explícitamente los objetos URL que crea o deja que el servidor decida? Si los nombra, utilice PUT. Si deja que el servidor decida, utilice POST.
- PUT se define para asumir idempotencia, por lo que si PONE un objeto dos veces, no debería tener ningún efecto adicional. Esta es una buena propiedad, por lo que usaría PUT cuando sea posible. Solo asegúrese de que la idempotencia PUT esté implementada correctamente en el servidor.
- Puedes actualizar o crear un recurso con PUT con la misma URL del objeto
- Con POST puede recibir 2 solicitudes al mismo tiempo para realizar modificaciones en una URL y pueden actualizar diferentes partes del objeto.
Un ejemplo:
Escribí lo siguiente como parte de otra respuesta en SO con respecto a esto :
CORREO:
Se utiliza para modificar y actualizar un recurso.
POST /questions/<existing_question> HTTP/1.1 Host: www.example.com/Tenga en cuenta que lo siguiente es un error:
POST /questions/<new_question> HTTP/1.1 Host: www.example.com/Si la URL aún no se ha creado, no debería utilizar POST para crearla mientras especifica el nombre. Esto debería resultar en un error de "recurso no encontrado" porque
<new_question>aún no existe. Primero debe PONER el<new_question>recurso en el servidor.Sin embargo, podrías hacer algo como esto para crear recursos usando POST:
POST /questions HTTP/1.1 Host: www.example.com/Tenga en cuenta que en este caso no se especifica el nombre del recurso, se le devolverá la ruta URL del nuevo objeto.
PONER:
Se utiliza para crear un recurso o sobrescribirlo. Mientras especifica la nueva URL de los recursos.
Para un nuevo recurso:
PUT /questions/<new_question> HTTP/1.1 Host: www.example.com/Para sobrescribir un recurso existente:
PUT /questions/<existing_question> HTTP/1.1 Host: www.example.com/
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.
Puedes encontrar afirmaciones en la web que dicen
- POST debe usarse para crear un recurso y PUT debe usarse para modificar uno.
- PUT debe usarse para crear un recurso y POST debe usarse para modificar uno.
Ninguno de los dos está del todo bien.
Es mejor elegir entre PUT y POST según la idempotencia de la acción.
PUT implica colocar un recurso, reemplazando completamente lo que esté disponible en la URL dada por algo diferente. Por definición, un PUT es idempotente. Hazlo tantas veces como quieras y el resultado será el mismo. x=5es idempotente. ¡Puedes PONER un recurso ya sea que exista previamente o no (por ejemplo, para Crear o Actualizar)!
POST actualiza un recurso, agrega un recurso subsidiario o provoca un cambio. UN POST no es idempotente, en el sentido de que x++no es idempotente.
Según este argumento, PUT es para crear cuando conoces la URL de lo que vas a crear. POST se puede utilizar para crear cuando conoce la URL de la "fábrica" o administrador de la categoría de cosas que desea crear.
Entonces:
POST /expense-report
o:
PUT /expense-report/10929
- POST en una URL crea un recurso secundario en una URL definida por el servidor .
- PUT en una URL crea/reemplaza el recurso en su totalidad en la URL definida por el cliente .
- PATCH a una URL actualiza parte del recurso en esa URL definida por el cliente.
La especificación relevante para PUT y POST es RFC 2616 §9.5ff.
POST crea un recurso secundario , por lo que POST /itemscrea un recurso que se encuentra debajo del /itemsrecurso. P.ej. /items/1. Enviar el mismo paquete postal dos veces creará dos recursos.
PUT sirve para crear o reemplazar un recurso en una URL conocida por el cliente .
Por lo tanto: PUT es solo un candidato para CREATE donde el cliente ya conoce la URL antes de que se cree el recurso. P.ej. /blogs/nigel/entry/when_to_use_post_vs_putya que el título se utiliza como clave de recurso
PUT reemplaza el recurso en la URL conocida si ya existe, por lo que enviar la misma solicitud dos veces no tiene ningún efecto. En otras palabras, las llamadas a PUT son idempotentes .
El RFC dice así:
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,
Nota: PUT se ha utilizado principalmente para actualizar recursos (reemplazándolos en su totalidad), pero recientemente hay un movimiento hacia el uso de PATCH para actualizar recursos existentes, ya que PUT especifica que reemplaza el recurso completo. RFC 5789.
Actualización 2018 : hay un caso que se puede presentar para evitar PUT. Ver "REST sin PUT"
Con la técnica "REST sin PUT", la idea es que los consumidores se vean obligados a publicar nuevos recursos de solicitud "nounificados". Como se analizó anteriormente, cambiar la dirección postal de un cliente es un POST a un nuevo recurso "ChangeOfAddress", no un PUT de un recurso "Cliente" con un valor de campo de dirección postal diferente.
tomado de REST API Design - Modelado de recursos por Prakash Subramaniam de Thoughtworks
Esto obliga a la API a evitar problemas de transición de estado con varios clientes actualizando un único recurso y coincide mejor con el abastecimiento de eventos y CQRS. Cuando el trabajo se realiza de forma asincrónica, parece apropiado PUBLICAR la transformación y esperar a que se aplique.
