Quando si dovrebbe utilizzare GET invece di POST in un'applicazione Web?

Question

Sembra che attenersi a POST sia la strada da percorrere perché risulta in URL dall'aspetto pulito. GET sembra creare lunghi URL confusi. POST è anche meglio in termini di sicurezza. Ottimo per proteggere le password nei moduli. In effetti, sento che molti sviluppatori usano solo POST per i moduli. Ho anche sentito che molti sviluppatori non usano mai veramente lo GET.

Quindi perché e in quale situazione si dovrebbe usare GET se POST ha questi 2 vantaggi?

Quali vantaggi ha oltre POST?

Answer 1

A volte si desidera che la propria applicazione Web sia rilevabile, poiché gli utenti possono solo indovinare quale URL dovrebbe essere per una determinata operazione. Fornisce un'esperienza utente migliore e per questo usereste GET e baserete i vostri URL su qualche tipo di specifica RESTful come http://microformats.org/wiki/rest/urls

Answer 2

avete ragione, tuttavia può essere meglio usare ottiene per le pagine di ricerca e così via. Luoghi in cui desideri che l'URL sia ovvio e individuabile. Se guardi la pagina di Google (o qualsiasi pagina di ricerca), inserisce una www.google.com/?q=my+search alla fine in modo che le persone possano collegarsi direttamente alla ricerca.

In realtà utilizzi molto più di quanto pensi. La semplice restituzione della pagina Web è una richiesta GET. Ci sono anche POST, PUT, DELETE, HEAD, OPTION e questi sono tutti usati nelle interfacce di programmazione RESTful.

GET vs. POST non ha implicazioni sulla sicurezza, sono entrambi insicuri a meno che non si utilizzi HTTP/SSL.

Answer 3

Se per "applicazione Web" si intende "sito Web", come sviluppatore non si ha alcuna scelta. Non sei tu come uno sviluppatore che fa le richieste GET o POST, è il tuo utente. Fanno le richieste tramite il loro browser web.

Quando si richiede una pagina Web digitandone l'URL nella barra degli indirizzi del browser (o facendo clic su un collegamento, ecc.), Il browser invia una richiesta GET.

Quando si invia una pagina Web utilizzando un pulsante, si effettua una richiesta POST.

In una richiesta GET, nella stringa di query vengono inviati dati aggiuntivi. Ad esempio, l'URL www.mysite.com?user=david & password = fish invia i due bit di dati "utente" e "password".

In una richiesta POST, vengono inviati i valori nei controlli del modulo (ad esempio caselle di testo, ecc.). Questo non è visibile nella barra degli indirizzi, ma è completamente visibile a chiunque visualizzi il tuo traffico web.

Sia GET che POST sono completamente non sicuri a meno che non venga utilizzato SSL (ad esempio, gli indirizzi Web che iniziano con https).

Answer 4

Check the manual, sono sorpreso che nessuno abbia sottolineato che GET e POST sono semanticamente diversi e destinati a scopi completamente diversi.

Anche se può apparire in molti casi che non v'è alcuna differenza funzionale tra i 2 approcci, fino a quando hai provato tutti i browser, proxy e server di combinazione non sarà in grado di contare su che essere un consistente ogni caso. per esempio.i dispositivi mobili/i proxy spesso nascondono aggressivamente anche dove non sono richiesti (ma non ne ho mai visto uno che memorizza in modo errato una risposta POST).

Il protocollo non consente nient'altro che semplici tipi di dati scalari come parametri in un GET - ad es. puoi solo inviare un file usando POST o PUT.

Ci sono anche dei limiti di implementazione: l'ultima volta che ho controllato, la dimensione di un URL era limitata a circa 2k in MSIE.

Infine, come è stato notato, c'è il problema della visibilità dei dati: è possibile che non si desideri consentire agli utenti di aggiungere ai segnalibri un URL contenente il proprio numero/password della carta di credito.

POST è la strada da percorrere, perché si traduce in pulite URL cerca

che invece contrasta con l'obiettivo di ciò che un URL è tutto. Leggi RFC 1630 - The Need For a Universal Syntax.