El verbo HTTP PUT se supone que es idempotent , un inteligente Palabra que significa que enviar dos veces la solicitud no debería tener ningún otro efecto. La idea es que un comando "PUT" es el opuesto a "GET": se supone que los contenidos de datos enviados con un "PUT" se almacenan en la URL especificada, y se pueden obtener de manera conceptual desde esa misma URL con un "GET ". En ese sentido, PUT y GET imitan el comportamiento esperado de FTP .
Por otra parte, un "POST" es el verbo genérico para llamadas similares a API: órdenes enviadas a un servidor para su ejecución inmediata. Tales llamadas a la API no son idempotentes. Una llamada de "cambio de contraseña" probablemente debería considerarse como una llamada a la API, no como una transferencia de archivos. Por lo tanto, debe usar POST en lugar de PUT.
Consulte, por ejemplo, esta publicación del blog para más información sobre PUT vs POST.
Desde el punto de vista de seguridad , no hay una diferencia real entre PUT y POST: todo pasa a través de SSL, y es principalmente una cuestión de convención entre el cliente y el servidor. Mientras el cliente y el servidor se entiendan, la seguridad ofrecida por ambas solicitudes es la misma.
La diferencia teórica es que un cliente podría hacerse cargo de sí mismo para emitir una llamada PUT nuevamente en caso de falla de la red, mientras que no lo haría para un POST. En general, prefiere la semántica POST, y mantenga PUT only para la transferencia masiva de archivos donde dicha reemisión sería una buena característica, y no un problema.