GET vs. POST è davvero importante?

Question

Ok, conosco la differenza nello scopo. OTTENERE ottenere alcuni dati. Fai una richiesta e recupera i dati. Il POST dovrebbe essere usato per operazioni CRUD diverse da leggere, credo. Ma quando si tratta di farlo, il server si preoccupa davvero se sta ricevendo un GET vs. POST alla fine?

Answer 1

Dato che si sta scrivendo il software del server (presumibilmente), è importante se gli si dice di occuparsene. Se gestisci i dati POST e GET in modo identico, allora no, non lo è.

Tuttavia, il browser sicuramente si preoccupa. Aggiornare o fare clic su una pagina che hai ricevuto come risposta a un POST fa apparire il piccolo prompt "Sei sicuro di voler inviare di nuovo i dati", ad esempio.

Answer 2

L'utente deve essere in grado di contrassegnare la pagina risultante? Un'altra cosa a cui pensare è che alcuni browser/server limitano in modo errato la lunghezza dell'URI GET.

Modifica: nota di limitazione della lunghezza del carattere corretto - grazie ars!

Answer 3

No, non dovrebbero eccetto la risposta @ jbruce2112 e il caricamento dei file richiede POST.

Answer 4

GET presenta limitazioni sul lato browser. Ad esempio, some browsers limitare la lunghezza delle richieste GET.

Answer 5

Penso che una risposta più appropriata, è che puoi praticamente fare le stesse cose con entrambi. Non è tanto una questione di preferenza, tuttavia, ma una questione di uso corretto. Ti consiglio di utilizzare GET e POST come sono stati utilizzati destinati a.

Answer 6

Lo fa se un motore di ricerca sta eseguendo la scansione della pagina, poiché eseguirà richieste GET ma non POST. Diciamo che avete un link sulla tua pagina:

http://www.example.com/items.aspx?id=5&mode=delete 

senza una sorta di controllo delle autorizzazioni eseguita prima della cancellazione, è possibile che Googlebot potrebbe come in and delete items sulla tua pagina.

Answer 7

Dipende dal software sul lato server. Alcune librerie, come CGI.pm in perl, gestiscono entrambe per impostazione predefinita. Ma ci sono situazioni in cui è più o meno necessario utilizzare POST anziché GET, almeno per spingere i dati sul server. Grandi quantità di dati (dove l'url GET corrispondente diventerebbe troppo lungo), dati binari (per evitare molti problemi di codifica/decodifica), file multipart, intestazioni non analizzate (per gli aggiornamenti continui in stile pre-AJAX ...) e simili .

Answer 8

Il server tecnicamente non può interessare in un modo o nell'altro il tipo di richiesta che riceve. Eseguirà ciecamente qualsiasi richiesta proveniente dal filo.

Qual è il problema. Se hai un'azione che distrugge o modifica i dati in un'azione GET, Google farà a pezzi il tuo sito mentre scorre attraverso l'indicizzazione.

Answer 9

Di solito il server non si preoccupa. Ma è soprattutto per seguire le buone pratiche, come hai detto. Anche il lato client è importante - come accennato, non è possibile aggiungere un segnalibro a una pagina POST di solito, e alcuni browser hanno limiti sulla lunghezza dell'URL per query GET molto lunghe.

Answer 10

Se si utilizza una richiesta GET per modificare lo stato del back-end, si corre il rischio che accadano cose brutte se un webcrawler di qualche tipo attraversa il sito.Quando i wiki sono diventati popolari, sono state cancellate le storie horror di interi siti perché la funzione "elimina la pagina" è stata implementata come richiesta GET, con risultati disastrosi quando Googlebot ha bussato ...

Answer 11

Dal momento che GET è destinato a specificando la risorsa che si desidera ottenere, a seconda del software esatto sul lato server, il server Web (o il bilanciamento del carico di fronte ad esso) può avere un limite di dimensione sulle richieste GET per impedire attacchi di tipo Denial of Service ...

Answer 12

" Usa GET if: l'interazione è più simile a una domanda (cioè, è un'operazione sicura come una query, un'operazione di lettura o ricerca). "

"Usa POST se: l'interazione è più come un ordine, o l'interazione cambia lo stato della risorsa in un modo che l'utente percepirebbe (ad esempio, un abbonamento a un servizio), o l'utente essere ritenuto responsabile per i risultati dell'interazione. "

source

Answer 13

Secondo la RFC HTTP, GET non dovrebbe avere alcun effetto collaterale, mentre POST può avere effetti collaterali.

L'esempio più semplice di questo è che GET non è appropriato per qualcosa come una transazione di acquisto o la pubblicazione di un articolo su un blog, mentre il POST è appropriato per le azioni-che-hanno-conseguenze.

Con RFC, è possibile mantenere un utente responsabile delle azioni eseguite dal POST (come un acquisto), ma non per le azioni GET. I robot usano sempre GET per questo motivo.

Dal RFC 2616, 9.1.1:

9.1.1 metodi sicuri

Implementors dovrebbero essere consapevoli che il software rappresenta l'utente in
loro interazioni su Internet, e dovrebbe essere attenti per consentire all'utente di di essere a conoscenza di eventuali azioni che potrebbero essere eseguite da che potrebbero avere un
significato inaspettato a se stessi o altri.

In particolare, la Convenzione è stato stabilito che il GET e
metodi di testa non deve avere la importanza di compiere un'azione
diverso recupero. Questi metodi devono essere considerati "sicuri". Questo permette programmi utente per rappresentare altri metodi, come POST, PUT e DELETE , in modo speciale, in modo che l'utente è a conoscenza del fatto che un'azione possibilmente pericoloso è essere richiesto.

Naturalmente, non è possibile assicurare che il server non
generare effetti collaterali a seguito di l'esecuzione di una richiesta GET; infatti, alcune risorse dinamiche considerano una funzionalità . L'importante distinzione qui è che l'utente non ha richiesto gli effetti collaterali , quindi non può essere ritenuto responsabile per loro.

Answer 14

GET ha restrizioni limite di dati basati sul browser di invio:

Le specifiche per la lunghezza URL non dettare un minimo o massimo la lunghezza dell'URL, ma l'attuazione varia a seconda del browser. Su Windows: Opera supporta ~ 4050 caratteri, IE 4.0+ supporta esattamente 2083 caratteri, Netscape 3 -> 4.78 supporta fino a 8192 caratteri prima di causare errori allo spegnimento e Netscape 6 supporta ~ 2000 prima di causare errori all'avvio

Answer 15

Tenere presente che i browser possono memorizzare nella cache richieste GET ma generalmente non memorizzano nella cache le richieste POST.

Answer 16

In base alle specifiche HTTP, GET è sicuro e idempotente e POST non lo è. Ciò significa che una richiesta GET può essere ripetuta più volte senza causare effetti collaterali.

Anche se al server non interessa (e questo è improbabile), potrebbero esserci agenti intermedi tra il client e il server, che hanno tutti questa aspettativa. Ad esempio proxy per memorizzare nella cache i dati presso il proprio ISP o altri provider per migliorare le prestazioni. La stessa aspettativa è vera per gli acceleratori, ad esempio un plug-in di precaricamento per il tuo browser.

Così una richiesta GET può essere memorizzata nella cache (in base a determinati parametri), e se fallisce, può essere ripetuta automaticamente senza alcuna previsione di effetti dannosi. Quindi, davvero il tuo server dovrebbe sforzarsi di soddisfare questo contratto.

D'altra parte, il POST non è sicuro, non idempotente e ogni agente sa di non memorizzare nella cache i risultati di una richiesta POST, o di riprovare automaticamente una richiesta POST. Quindi, ad esempio, una transazione con carta di credito non sarebbe mai, mai, una richiesta GET (non si desidera che gli account vengano addebitati più volte a causa di errori di rete, ecc.).

Questa è una presa di base su questo. Per ulteriori informazioni, si potrebbe prendere in considerazione il libro "RESTful Web Services" di Ruby e Richardson (stampa O'Reilly).

Per un rapido introito sul tema del riposo, prendere in considerazione questo post:

http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx

La cosa divertente è che la maggior parte delle persone discutono i meriti del PUT v POST. Il problema GET v POST è, ed è sempre stato, molto ben definito. Ignoralo a tuo rischio e pericolo.

Answer 17

Sei consapevole di alcune sottili differenze di sicurezza. Vedere la mia domanda

GET versus POST in terms of security?

In sostanza, la cosa importante da ricordare è che ottenete andare nella cronologia del browser e saranno trasmessi attraverso i proxy in testo semplice, in modo che non si vuole tutte le informazioni sensibili , come una password in un GET.

Ovvio forse, ma vale la pena menzionare.

Answer 18

Sì, importa. GET e POST sono piuttosto diversi, davvero.

In questo caso è normale, GET serve per "prelevare" i dati dal server e visualizzare una pagina, mentre il POST serve per "postare" i dati sul server. Internamente, gli script ottengono gli stessi dati indipendentemente dal fatto che siano GET o POST, quindi no, al server non interessa molto.

La differenza principale è che i parametri GET sono specificati negli URL, mentre il POST no. Questo è il motivo per cui POST viene utilizzato per i moduli di iscrizione e di accesso: non si desidera la password in un URL. Allo stesso modo, se stai visualizzando pagine diverse o visualizzi una vista specifica di alcuni dati, normalmente desideri un URL univoco.

Answer 19

Tecnicamente, no. Tutto ciò che GET fa è pubblicare le cose nella prima riga della richiesta HTTP, e POST pubblica cose nel corpo.

Tuttavia, il modo in cui "l'infrastruttura Web" tratta le differenze fa un mondo di differenza. Potremmo scrivere un intero libro a riguardo. Tuttavia, ti darò alcune "buone pratiche":

Usa "POST" per quando la tua richiesta HTTP cambierebbe qualcosa di "concreto" all'interno del server web. Ad esempio, stai modificando una pagina, creando un nuovo record e così via. I POSTS hanno meno probabilità di essere memorizzati nella cache o trattati come "ripetibili senza effetti collaterali"

Utilizzare "GET" per quando si desidera "guardare un oggetto". Ora, un tale sguardo potrebbe cambiare qualcosa "dietro le quinte" in termini di memorizzazione nella cache o conservazione dei documenti, ma non dovrebbe cambiare nulla di "sostanziale". Cioè, potrei ripetere il mio GET ancora e ancora e non succederà nulla di brutto, tranne che per i conteggi dei colpi inflazionati. I GET dovrebbero essere facilmente bookmarkable, quindi un utente può tornare a quello stesso oggetto in seguito.

I parametri del GET (il materiale dopo il?, Tradizionalmente) devono essere considerati "attributi per la vista" o "cosa visualizzare" e così via. Di nuovo, non dovrebbe in realtà cambiare nulla: usa POST per questo.

E, una parola finale, quando si POST qualcosa (ad esempio, si sta creando un nuovo commento), l'elaborazione per il post di un 302 di "reindirizzare" l'utente a un nuovo URL che visualizza quell'oggetto . Cioè, un POST elabora le informazioni, quindi reindirizza il browser a un'istruzione GET per visualizzare il nuovo stato. Anche la visualizzazione di informazioni come risultato di un POST può causare problemi. Spesso viene utilizzato il reindirizzamento e le cose funzionano meglio.