Perché dovrei inviare i dati POST anziché GET?

So che non si desidera POSTARE un modulo con un nome utente e una password in cui chiunque potrebbe utilizzare la cronologia per vedere o situazioni in cui le azioni ripetute potrebbero non essere desiderate (aggiornamento di una pagina = l'aggiunta di un articolo a un carrello potrebbe non essere desiderata). Quindi ho una comprensione quando potrei volerne usare uno sull'altro. Ma potrei sempre fare in modo che il server reindirizzi l'URL dopo un GET per aggirare il problema del carrello e forse la maggior parte dei miei moduli funzionerà perfettamente con GET.Perché dovrei inviare i dati POST anziché GET?

Perché dovrei usare POST su GET? Non capisco i benefici dell'uno sull'altro. Ho notato che POST non aggiunge dati alla cronologia/URL e ti avviserà sull'aggiornamento della pagina, ma queste sono le uniche due differenze che conosco. Perché come sviluppatore potrei volerne usare uno sull'altro?

fonte

2010-05-31 Anonymous

L'aggiunta di articoli al carrello con GET è una cattiva idea poiché le richieste GET non dovrebbero mai avere effetti collaterali sul server. Esistono programmi di prefetching come FasterFox e Google Web Accelerator che precaricano il contenuto da link su una pagina scaricando le pagine in anticipo. Se sei sfortunato potrebbero finire per aggiungere articoli al carrello quando l'utente sta semplicemente leggendo una pagina di prodotto. – Martin

@ Martin. Questo ha senso. Che ne dici di ajax saggio? C'è una differenza se uso GET o POST? Niente può prevedere i dati che sto inviando se devo correre attraverso alcune funzioni javascript effettuare la richiesta. –

I prefetcher non dovrebbero essere un problema per le richieste AJAX, ma ritengo comunque che sia una buona idea attenersi alla semantica corretta: GET reqs non deve avere effetti collaterali sul server (cioè non creare, eliminare o modificare nulla). Se stai semplicemente recuperando dati (ad esempio per una casella di completamento automatico) e i dati inviati sono abbastanza piccoli da contenere un URL, GET dovrebbe funzionare correttamente. A differenza delle risposte POST, le risposte GET possono persino essere memorizzate nella cache, il che migliora le prestazioni percepite dell'app. – Martin

Ogni metodo HTTP: POST, GET, PUT, DELETE, ecc. Carie la propria semantica. Quando si sceglie il metodo giusto, è importante capire l'HTTP e lo REST, poiché è il modo in cui HTTP avrebbe dovuto funzionare e il modo in cui opera l'infrastruttura di rete sottostante.

Un buon tutorial su REST è disponibile here. Ecco ciò che è dice di POST e GET metodi:

Perché la stessa interfaccia viene utilizzata per ogni risorsa, si può fare affidamento sul fatto di poter recuperare una rappresentazione - vale a dire, alcuni rendering di esso - con GET. Poiché la semantica di GET è definita nelle specifiche, puoi essere certo di non avere obblighi quando la chiami: ecco perché il metodo è chiamato "sicuro". GET supporta il caching molto efficiente e sofisticato, quindi in molti casi non è nemmeno necessario inviare una richiesta al server. Puoi anche essere sicuro che un GET è idempotente: se invii una richiesta GET e non ottieni un risultato, potresti non sapere se la tua richiesta non ha mai raggiunto la sua destinazione o se la risposta è andata persa mentre tornava da te.

La garanzia di idempotenza significa che è possibile semplicemente inviare nuovamente la richiesta. L'idempotence è anche garantita per PUT (che in pratica significa "aggiorna questa risorsa con questi dati, o creala con questo URI se non è già presente") e per DELETE (che puoi semplicemente provare ancora e ancora fino ad ottenere un risultato - eliminazione qualcosa che non c'è non è un problema).Il POST, che in genere significa "crea una nuova risorsa", può essere utilizzato anche per richiamare l'elaborazione arbitraria e quindi non è né sicuro né idempotente.

fonte

2010-05-31 22:58:56 Dan

Ho guardato prima quella pagina di riposo. Non è stato utile. Non vedo ancora perché dovrei usare l'altro eccetto per le 2 differenze che ho menzionato. Non vedo perché molte delle mie richieste di lettura/scrittura non dovrebbero essere ottenute (è più facile per me ...) –

IMHO, capire REST è la chiave per rispondere alla tua domanda. Ho aggiunto il link a un altro articolo introduttivo di REST e ho citato la sezione in cui spiegano i metodi sicuri e idempotenti. È importante capire che l'infrastruttura Web sottostante (proxy, gateway, ecc.) Funzionerà in conformità con REST (o specifiche HTTP). – Dan

Tutti i dati in una richiesta GET vengono trasportati nell'URL, che ha una limitazione di dimensioni ed è anche visibile all'utente. Una richiesta POST consente di inviare anche un carico utile.

In aggiunta alle differenze tecniche, c'è la questione dell'intenzione. Lo standard HTTP descrive i modi in cui le diverse richieste (GET, POST, PUT, DELETE, HEAD) devono essere utilizzate; ad esempio, PUT è destinato ad aggiungere una risorsa, DELETE è destinato a rimuovere uno, e POST è destinato a modificare uno. Potresti utilizzare una richiesta GET anziché PUT o DELETE? Certo, ma seguire gli standard rende esplicito l'intento.

Vedere http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html per ulteriori informazioni.

fonte

2010-05-31 22:50:54 danben

In che modo l'intento fa la differenza? Non ricordo dove l'ho visto, ma ho notato che i dati POST non aggiornavano la cache della pagina, quindi sembra che un get avrebbe fatto la stessa cosa –

Ti riferisci a implementazioni specifiche di client e server. Davvero, sono liberi di fare ciò che vogliono. Non c'è nulla che ti impedisca, dal punto di vista funzionale, di scrivere un server web che rimuova le risorse su ogni 'GET', aggiunge risorse su ogni 'DELETE', ecc. Ma tu saresti arrabbiato se tu fossi il client e' GET' stavi cancellando risorse, perché questo non è quello che ci aspettiamo succederà. Ecco perché l'intento fa la differenza. – danben

In un altro modo, in OOP si potrebbe chiedere perché si dovrebbe usare 'getProperty()' solo per recuperare una proprietà e 'setProperty()' solo per impostarla, quando si potrebbe fare il contrario altrettanto facilmente. Avere uno standard ci impedisce di essere sorpresi. – danben

Tra le altre cose, ottenere è limitato a 2K (alcuni browser accetteranno più) ed è visibile nella URL

fonte

2010-05-31 22:52:11 SQLMenace

Se si desidera un idempotent richiesta di URI (cioè la risposta è sempre lo stesso), quindi usa GET, altrimenti POST.

fonte

2010-05-31 22:53:46 BalusC

se ricevo /blah.aspx e post in/cmd fa/blah cambia? Inoltre ho visto da qualche parte dove il GET era cache anche dopo un post (forse era un bug del browser? Ma non sembrava importare se i dati fossero GET o POST-ed) –

La risposta non è necessariamente la stessa, non c'è proprio effetti collaterali osservabili dalle richieste ripetute. Questa pagina non sarà sempre la stessa, ma io, RACCOGLIENDO più volte, non causerò un effetto collaterale osservabile (almeno per me, Jeff e Co. potrebbero notare un sacco di accessi al registro, ecc. Ma quelli sono rilevanti per utente) –

Mark Brackett: Quindi sembra che tu stia dicendo che a GET è permesso un prefetch dove il post non lo è. Ma il precaricamento di un modulo non ha senso e in questo momento lo sto facendo con ajax che non ha senso dal momento che non può prevedere l'input javascript di cui avrà bisogno. –

GET e POST hanno un significato semantico: GET viene utilizzato per recuperare una risorsa e il POST viene utilizzato per modificarlo. La semantica è il motivo per cui si notano le differenze di implementazione nel proprio browser Web: poiché il POST modifica presumibilmente i dati, un browser dovrebbe avvisare prima di inviare nuovamente una richiesta/comando POST.

L'interezza del web va su quella semantica. È sicuro memorizzare nella cache una richiesta GET, ma non un comando POST, quindi questo è ciò che fanno i proxy di caching. È sicuro OTTENERE una risorsa più volte, quindi hai prefetcher di link che fanno proprio questo. È sicuro aggiungere segnalibri e aggiornare GET, quindi non c'è alcun avviso dai browser, ecc. Ecc.

Detto questo, non c'è alcuna differenza di sicurezza, quindi l'esempio di password del nome utente che si fornisce non è esattamente preciso. POST è facilmente manomesso o visualizzato come GET.

fonte

2010-05-31 23:02:21

Sì ma non è nella cronologia e può essere recuperato mesi dopo (se ancora esiste). Una domanda è, se faccio un get/a può essere memorizzato nella cache e se post/b i risultati non saranno memorizzati nella cache, ma se visito/a di nuovo avrei ancora i vecchi dati nella cache? posta la cache di riposo sul dominio? o dice semplicemente di non memorizzare nella cache questa pagina specifica? –

@ acidzombie: dice solo di non memorizzare nella cache questa richiesta. –

Perché dovrei inviare i dati POST anziché GET?

risposta

Problemi correlati