Il PUT verbo HTTP dovrebbe essere idempotente , uno smart parola che significa che inviare due volte la richiesta non dovrebbe avere ulteriori effetti. L'idea è che un comando "PUT" è l'opposto di "GET": i contenuti dei dati inviati con un "PUT" devono essere memorizzati nell'URL specificato e possono essere ottenuti concettualmente dallo stesso URL con un "GET ". A questo proposito, PUT e GET imitano il comportamento previsto di FTP .
D'altra parte, un "POST" è il verbo generico per le chiamate tipo API: ordini inviati a un server per l'esecuzione immediata. Tali chiamate API non sono idempotenti. Una chiamata "cambia password" dovrebbe probabilmente essere immaginata come una chiamata API, non un trasferimento di file. Pertanto, dovresti usare POST invece di PUT.
Vedi ad esempio questo post del blog per ulteriori discussioni su PUT vs POST.
Da un punto di vista sicurezza , non c'è alcuna differenza tra PUT e POST: tutto passa attraverso SSL, ed è principalmente una questione di convenzione tra client e server. Finché il client e il server si capiscono, la sicurezza offerta da entrambe le richieste è la stessa.
La differenza teorica è che un client potrebbe assumere se stesso per emettere nuovamente una chiamata PUT in caso di errore di rete, mentre non lo farebbe per un POST. In genere, preferisci la semantica POST e mantieni PUT solo per il trasferimento di file di massa in cui tale riemissione sarebbe una funzionalità piacevole e non un problema.